I'm glad that the scrambled output buffers was not a psycho. Imagine what he would do
in databasic.
I worked at MCD when PQN came out and we got tricky as a PQ proc couldn't reference a
PQN proc and vice versa. So you either changed all the procs or bounced the command
off the MD. Since MCD didn't get PERFORM until around 1984-5, I got real good with PQN
to the point of doing file read/writes, readnexts, iconv, oconv and multiple commands
on the same line (saves the branching). A great improvement was being able to validate
date answers using iconv instead of pattern matching as (2n/2n/2n) which 12/34/56
would be acceptable. For whatever reason, i really understood procs with all the
buffers and user exits.
Speaking as someone very versed in both F and A correlatives, i initially missed them
with my UD clients. I did get the hang of simple I types and i don't think i will ever
enjoy UD's version of stacking with I types. I like the OCONV(@ID,"T1,2") direct
expressions and you'll probably never catch me writing the SUBS -IFS(-IFS ones as
unfortunately all the examples i've seen in my clients are very hard to read and
understand.
One client had their system converted from Microdata to UD and there must have been a
dict converter as it put the original 10 line dict on line 10 and built the
appropriate 6 line dict. Unfortunately since the 10 line variety allows the false
start of primary field, many converted dicts look like this:
002 F99; F1; F2;@[EMAIL PROTECTED]
because the source dict had 002=99 and 008=A;F1+F2. Given the three choices to assign
to 002 in a 10 line dict item, many earlier programmers fell into a bad habit of
putting all of their calculating dict items either in 002=0 or 002=99. Once you
reference a field in 008, it doesn't matter what's in 002. So the converter wrote the
above 002 with the unnecessary F99.
I do enjoy writing SUBR dict items as i try to make those subs usable by regular
databasic programs as well. There are a bunch of things that i like doing in SUBR
(UD/UV or D3) that you cannot do in any real dict item. Very handy.
thanks
----- Original Message -----
From: [EMAIL PROTECTED]
To: U2 Users Discussion List
Sent: Thursday, February 05, 2004 1:23 PM
Subject: Re: [UD] Determining if list exists
Good Heavens, Mark, I think you kind of missed the tone of my post. :-) I see you
sent it just before midnight, you must have been tired.
I suppose after rereading my post in the light of a new day, you will see that I
understand why the code I copied from a prior post was poorly written. (Don't believe
in your wildest dreams, I would have written something like that.) And, as you are
rereading my posting, you will also come to understand that the second proc was a
joke based upon the poor understanding of procs by so many programmers. If you got
the joke, you must understand something about proc.
After 21 years in PICK, I know PQ procs and how to use them to best advantage. I
have to admit PQN procs I have to look up syntax. I must admit, as much as I like
procs, I don't use them much anymore.
Now if only UniData would support F-correlatives... (Mark, that is another joke. :-)
)
Take care,
Bruce M Neylon
Health Care Management Group
"Mark Johnson" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/04/2004 11:52 PM
Please respond to U2 Users Discussion List
To: "U2 Users Discussion List" <[EMAIL PROTECTED]>
cc:
Subject: Re: Re: [UD] Determining if list exists
Your proc example doesn't need the P after the STON in line 3. The reasons you have
the STON, H< and P(x) on lines 7,8,9 is twofold. The first reason is that in a typical
GET-LIST/LIST pairing, your list statement could exceed the maximum size of the
Secondary Output buffer (STON without the H< and P). That required Secondary Output
buffer extensions of H<< which needed to be properly placed and when changes were
made, you had to recalculate where they belonged.
Using the STON, H<, P then the HLIST put the entire LIST statement into the Primary
Output buffer which is seemingly limitless. Like a paragraph, you were executing 2
consecutive statements.
The downside is that if the preceeding SELECT doesn't yield any items or the
GET-LIST comes up empty, the HLIST will process your report against the entire file.
Thus the IF E=401 concept was introduced to validate the active list.
That psycho couldn't possibly have programmed that on purpose. I've seen some
excessive use of STOFF/STON pairs, ie STOFF after a P when it comes automatically.
(Like RI then S1. Duh, RI implies S1). The fact that the psycho alternated their two
sentence's words in consecutive statements was either to hide some code or fool
around.
my 1 cent
------------------------------------------------------------------------------
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users
