Date: Mon, 13 Jul 1998 16:50:24 -0400
Reply-To: Aston Lexmart <alexmart@JUNIK.LV>
Sender: "SAS(r) Discussion" <SAS-L@UGA.CC.UGA.EDU>
From: Aston Lexmart <alexmart@JUNIK.LV>
Subject: Re: Modular recursion in COBOL and SAS (was: Re:Recursion in
SAS-the exact query)
Content-Type: text/plain; charset=us-ascii
i can be silent no longer. not only you posted to the wrong group but you
the same very verbose posting two times.
> Curiously enough, COBOL can make recursive calls to PERFORMs. Years ago, I
> to write a COBOL routine that would traverse a non-binary hierarchical tree
> "collect" its leaf nodes. Once a new non-leaf node is encountered, the same
> algorithm should start all over again, so it was fairly apparent that a
> recursive code would look something like
> ...PERFORM SOMETHING...
> IF SOME-CONDITION
> PERFORM 1000-TRAVERSE
> ...PERFORM SOMETHING-ELSE...
> PERFORM 1000-TRAVERSE
if you never wrote to a group, check its name first. this is sas, not cobol.
knows sas don't use cobol for nothing and dont need to know all that stuff you
write about. write to comp.lang.cobol if you want to discuss cobol. Here in
sas-l we discuss sas.
> Of course, this is not a recursive function call, but a recursive process
> However, coded this way, the program did not work. The compiler would issue a
> warning, yet compile anyway. After some number of properly done recursive
> the program would usually abend with S0C4. Contrary to that , once the
> recursive PERFORM was replaced by GO TO, everything worked just fine, even
> though the warning persisted.
> (Needless to say, both recursion and GO TO were severely against the shop's
> COBOL standards. The only reason I was not fired was because nobody figured
> how to do the same iteratively in spite of loud bragging to the contrary).
they shouldn't of hired you in the first place becuz if you were cobol
programmer you would of known any cobol program can be coded without recursion.
if cobol program has recursion nibody can support it.
> Back then, I figured out (maybe, wrong) that the difference was due to the
> PERFORM behavior behind the scenes: "execute the paragraph, then go to the
> instruction", and the next instruction was nowhere to be found. So, the
> wild-branched to a deliberate location, usually invading a foreign memory
> region, hence bombing with S0C4.
i used to program cobol too but no more since now i do only sas. but i have
enough experoence to tell you that it would of never been soc4 if you would of
tried to access another user memory, maybe soc1 or soc5.
> It was very interesting to find out whether SAS would be as unfriendly as
> if an attempt were made to implement a recursive call to LINK, SAS's analog
why would you need a recursive call to link. i doubt you can write macros but
you could you wouldn't need to use link becuz macros are more powerful. if
macros were in cobol like in pl1 nobody would use performs. btw, do you check
your programs the same way you check you grammar? 'attempt' is singular and in
tihs context should of been followed by 'was'.
> Can SAS swallow a self-LINK without choking? Let us consider an
> example. Suppose we have an unsorted array. We want to place its first
> A(1) where it would be if the array were sorted ascending, so that all
> less than A(1) would be to the left of its final location, and all the
> greater than A(1) - to the right. (Of course, you have recognized the basic
> building block of Quicksort). One way to code the process would be:
nobody asked you to write no code. if you want people to use quicksort post all
code, not your 'buiding block'. you pretend you know how to write sas quicksort
but you cant know as it can be written only in c or asembler.
> By the way, this example also shows that, contrary to what some COBOL people
> say, COBOL-type paragraphizing can be easily emulated in the SAS DATA step. A
> LINK routine together with its label and RETURN statement surrounded by "IF
> THEN DO;" and "END;" does not execute unless called, and as such, can be
> anywhere in the DATA step. On a number of occasions, I have found this method
> quite handy, in particular, whenever heavy modularizing was desirable within
> boundaries of the DATA step.
cobol people don't know nothing about sas, therefore they cant say nothing.
if you want to use link anyways. if you read sas manual carefully you would of
known that you can put all labels after return, and then you dont need all that
stuff with 'if 0' or something. to make it look like it makes sense you use all
these big words like 'heavy modularizing' and 'boundaries of the DATA step'.
btw, for the future use simple language so all people on sas-l could understend
what you mean.
> Could not avoid the temptation to toss my $.02 into this SASCOBOL bucket...
it would be better for sas-l community if you avoided it and didn't pollute
group with postings that don't have no useful thoughts. nobody asked you no
question or advise. if at least you had some practically useful code to share
but your code serves no purpose. at least, like i said it can't be used in
quicksort anyways. when others ask you for a simple answer or some normal
code you keep silence. but you grab a big word from someone's posting like
recursion and cobol and spread all that philosofy around it.
and we don't need no cobol in sas group.
i know people on sas-l are too polite to tell you what they really think. they
may have their reasons but i don't really care and say what i think, and i
all sas-l community will benefit from it and especially folks who are really
annoyed when they see your name but don't say nothing.
No hard feelings,