Martin: These are some holy grails that would be wonderful if found.
One client of mine that was on Results (Microdata) then Universe and is
now
on D3, still has the original Results PQN procs.
Fortunately those procs did not use the extended &, # and ! variable
nomenclature but use the % nomenclature very often. Their solution
attacked
the MV command in this way:
Original:
MV %1 "Mark"
New:
HMV %1 "Mark"
P
whereby they had created a program called MV that would interpret the
request. It uses PROCREAD/WRITE. The downside is that this databasic
program
could not interpet MV &1.4 %10 or MV #1 "SORT MD" as it had no access to
those buffers.
So one small step for mankind.
Regarding "A" correlatives to I Descriptors. One of my clients uses Media
Services Group's Advertising billing system and from the looks of the
code,
it used to be on R90 then Universe then now on Unidata. All of the
dictionary items that used to be "A" correlatives had gone through a
conversion utility to create the I descriptors. That utility saved on line
10 the original 10 line R90 dict item using IIRC value marks. Thus, the
original dict item (for me to more easily understand) exists on the
ignored
line 10.
I never got good at the interpreted version of I descriptors (NEQS, EQS
and
the nested command structure) so I assumed that the conversion was okay. I
write CALL I descriptors if the dict item gets busy.
I will offer this though. As a straight programmer for individual clients
(not a VAR, reseller or employee at one location), it may not be worth it
to
'fix what ain't broke' regarding replacing their working procs with all
data/basic.
But I think it would be a matter of uniformity and forward compliance for
those VAR, reseller or employee-level members of this forum to engage in
the
project of replacing procs with programs. For the VAR's, it would be a
continued investment in their product. For the employees, it would remove
one of the legacy entities that may become harder to find younger
programmers who can (or want to) understand Procs beyond the bvious
jobstreams.
My 3 cents
Mark Johnson
----- Original Message -----
From: "Martin Phillips" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 01, 2008 2:56 PM
Subject: Re: [U2] UniData PROC tip: DB command
Hi,
> The man (person) who writes a PROC interpreter/conversion utility
> that can take a PROC and turn it into either Basic, or a PAragraph,
> will
> have a product to sell... esp. if it can decipher all the PROC nuances
and
> tricks that have been introduced over the years.
Back in the days when I was working on the development of PI/open, I had
a
go at this. It is not difficult to produce Basic code that does the same
job
as the Proc but producing good code rather than a simple step by step
interpretation of the Proc is difficult. Also, there are some strange
interactions between Procs and the underlying command environment that
are
different from how Basic programs work so you can never get a true
replacement.
> Same goes for a tool to convert A correlatives to I-descriptors.
This is relatively easy. If you think there is a market, we might even do
it. We looked at this as part of the migration process for users moving
to
OpenQM but we chose to implement correlatives instead as it was easy.
Ours
are compiled (like an I-type) rather than interpretive for best
performance
so actually the task of writing the convertor is probably little more
than
ripping apart our existing correlative compiler.
> But pity the wretch that is assigned the task of writing the tool to
> convert
> F correlatives.
This is probably easier than A correlatives. Again, if there is a real
market that would pay a sensible price for it, we might do it.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
