Dict CALL routine to return MV data

#21

On Apr 9, 11:39 am, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

Quote:

"dtsig" wrote:
Simple facts. I can't bring back a mv field. There is no way to use
LIST to report the data. I have to write the report in code.

You are right .. not too much of a problem here. As I work with D3 i
lower my expectations. And that is alright.

Dave, I've cited this many times as being the most requested feature
I've ever seen for D3. If you haven't yet done so (haven't been
tracking this thread too closely because it's essentially a repetition
of so many we've already seen), I recommend you file a request with
RD, just to ensure you get in your "me too". Considering this feature
has been requested for every release at least since 1995, I doubt RD
will make the enhancement, but let's leave such things to them, our
job is to just report what we need.

For now, you're right, you need to use a program to be able to
simulate the functionality where a translate returns an MV field. You
absolutely can't do this with AQL.

However, while I don't particularly like this solution, you could
reformat your data as part of your reporting process, bringing primary
and translated data in-line to a work file and reporting on that.
Gasp, sigh, ugh, ptooey, this is an awful solution, but no less kludgy
than some of the other crap that people use for solutions with MV
software. You face one of two choices: write code or reformat data.
When put in those terms it seems both options are equally distasteful,
so I'd just evaluate the details and decide on what seems to be the
least painful and most maintainable solution.

Similarly, and I trust one of our colleagues might have suggested this
already, rather than doing this on an as-needed basis, you might want
to consider enhancing the app code so that when it writes to primary
files it also updates a reporting work file with everything you need
for a given report. Again we're just shifting the pain from code
dedicated to a specific report to putting (probably) smaller amount of
code elsewhere, but I think this is yet another solution that should
be considered.

As far as accepting the limitations of D3, in all sincerity I suggest
you also endeavor to find the features of D3 which do work and are not
supported by other MV platforms - there are a lot of them. D3 is
basically good software but there is a disconnection between the
engineering people who put the code in and the marketing people who
tell you what's in there. Oops, at this point there are no marketing
people so you're left to reading manuals or calling Support. This is
another problem that's RD's own responsibility to fix or not, and to
deal with the consequences.

HTH
T
(writing fast, hope that made sense)

As far as accepting the limitations of D3, in all sincerity I suggest
you also endeavor to find the features of D3 which do work and are not

supported by other MV platforms - there are a lot of them.

I agree that D3 is good. It is possibly the best *engine* i have ever
worked with. It is fast and efficient. I am not sure about all the
'features' that it has that other MV do not have but ..

Quote:

D3 is basically good software but there is a disconnection between the
engineering people who put the code in and the marketing people who

tell you what's in there. Oops, at this point there are no marketing
people so you're left to reading manuals or calling Support. This is
another problem that's RD's own responsibility to fix or not, and to
deal with the consequences.

<g> i really agree here. This has been one of the deficiencies of
"PICK" and "MV" in general for quite a while. They all ebb and flow
with support but "PICK" has always seemed a problem child <G>

But then that is the ravings of a poor workman <G>

#22

Thanks Glen, I was waiting for that one. I use "]" as a VM
substitute in my AT GUI programs. It translates fine and I have
found no "]" characters in applications or DB Files/Tables.

Patrick, <;=)

P.S. Of course I do control what goes into the database.

Glen B wrote:

Quote:

If you are using it for list/sort capturing within another application
then you can have your dict CALL subroutine swap the VM/SVM characters with
those under 251 and then translate them back to the proper VM/SVM
characters. If you use it for screen display, then I don't see an issue with
the line breaks for VM and spaces for SVM.

Glen

"dtsig" <dtsig (AT) hotmail (DOT) com> wrote in message
news:1175120341.893448.131930 (AT) y80g2000hsf (DOT) googlegroups.com...
I have been told that D3 does not allow the return of MV data through
a dictionary call. Is this correct?

#23

It's been about 15 years, but, if memory serves, it ain't that hard to do,
other experts to the contrary. No "rewriting' of the aql processor is
needed. very simply, the columnar line formatter uses a set of action flags
to determine what to do on the next line. If, eg, a SVM is flagged, the next
line consists of only SVM data. when all such data has been formatted, the
SVM flag turns off, so we proceed with VM, if any. Etc.

So if a Translate returns mv's (or, for that matter, sv's,) pretty much all
that has to be done is to , copy the data somewhere for safety and setup the
standard register to the terminating delimiter (which is automatic anyway.)
The AQL processer sees a VM and does its thing. You do need a flag to return
to the "true" data stream. Takes about a week of work.

The real point, aside form all this detail is that we get this rubbish that
it's hard to change the aQL processor (or practically anything else in D3)
because Pick assembler is "hard". What a crock. Any average C program,
application or system level, gets to a level of obfuscation that far exceeds
the simplicity of PAL. Not to mention object oriented code, which requires a
level of concentration I, for example, could never possess.

Chandru
"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

Quote:

On Apr 9, 11:39 am, Tony Gravagno
address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
"dtsig" wrote:
Simple facts. I can't bring back a mv field. There is no way to use
LIST to report the data. I have to write the report in code.

You are right .. not too much of a problem here. As I work with D3 i
lower my expectations. And that is alright.

Dave, I've cited this many times as being the most requested feature
I've ever seen for D3. If you haven't yet done so (haven't been
tracking this thread too closely because it's essentially a repetition
of so many we've already seen), I recommend you file a request with
RD, just to ensure you get in your "me too". Considering this feature
has been requested for every release at least since 1995, I doubt RD
will make the enhancement, but let's leave such things to them, our
job is to just report what we need.

For now, you're right, you need to use a program to be able to
simulate the functionality where a translate returns an MV field. You
absolutely can't do this with AQL.

However, while I don't particularly like this solution, you could
reformat your data as part of your reporting process, bringing primary
and translated data in-line to a work file and reporting on that.
Gasp, sigh, ugh, ptooey, this is an awful solution, but no less kludgy
than some of the other crap that people use for solutions with MV
software. You face one of two choices: write code or reformat data.
When put in those terms it seems both options are equally distasteful,
so I'd just evaluate the details and decide on what seems to be the
least painful and most maintainable solution.

Similarly, and I trust one of our colleagues might have suggested this
already, rather than doing this on an as-needed basis, you might want
to consider enhancing the app code so that when it writes to primary
files it also updates a reporting work file with everything you need
for a given report. Again we're just shifting the pain from code
dedicated to a specific report to putting (probably) smaller amount of
code elsewhere, but I think this is yet another solution that should
be considered.

As far as accepting the limitations of D3, in all sincerity I suggest
you also endeavor to find the features of D3 which do work and are not
supported by other MV platforms - there are a lot of them. D3 is
basically good software but there is a disconnection between the
engineering people who put the code in and the marketing people who
tell you what's in there. Oops, at this point there are no marketing
people so you're left to reading manuals or calling Support. This is
another problem that's RD's own responsibility to fix or not, and to
deal with the consequences.

HTH
T
(writing fast, hope that made sense)

To All...

Mr. Brown eluded to the complexity of the change that is required...
The AQL process is expecting one line, and the data brought back
through the T-File look up requires multiple lines!

My quasi-semi-educated guess is that major under pinnings to the
current AQL processor would need reworking to allow a change in the
order of the processing. That is to fetch the data first and then to
figure out how to create the multiple report lines second.

I really don't think that this is a quick fix. Although Pick Systems
has had many many years to figure out a solution. Since D3 is
probably not the cash cow that it once was for RD, I suspect that the
selective hear mode is switched on.

As people switch off of Pick/D3 and onto other systems, the revenue
stream from D3 slowly dwindles for RD. And with the smaller income
come less dollars for changing current functionality. The Pick
community has been living with this short-come for a long time, and I
don't see RD saying lets relieve the users pain anytime soon.

Most of the long time Pick users already have routines and reports or
report writers to do what needs to be done.

Regards,

Dale

#24

On Apr 11, 5:44 am, "Chandru Murthi"
<cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote:

Quote:

It's been about 15 years, but, if memory serves, it ain't that hard to do,
other experts to the contrary. No "rewriting' of the aql processor is
needed. very simply, the columnar line formatter uses a set of action flags
to determine what to do on the next line. If, eg, a SVM is flagged, the next
line consists of only SVM data. when all such data has been formatted, the
SVM flag turns off, so we proceed with VM, if any. Etc.

So if a Translate returns mv's (or, for that matter, sv's,) pretty much all
that has to be done is to , copy the data somewhere for safety and setup the
standard register to the terminating delimiter (which is automatic anyway.)
The AQL processer sees a VM and does its thing. You do need a flag to return
to the "true" data stream. Takes about a week of work.

The real point, aside form all this detail is that we get this rubbish that
it's hard to change the aQL processor (or practically anything else in D3)
because Pick assembler is "hard". What a crock. Any average C program,
application or system level, gets to a level of obfuscation that far exceeds
the simplicity of PAL. Not to mention object oriented code, which requires a
level of concentration I, for example, could never possess.

I couldn't let this slide by for some reason. You might never wish to
code in OO, but I have no doubt you could muster up the concentration
as it doesn't take more than with traditional procedural (maybe even
less).

Data specified using OOP classes simply provides a spec for the schema
(a dict) such as PersonRecord or Person mentioned below, nothing that
would stretch your concentration levels, I'm sure. Additionally, to a
great extent OOP is just a standardized way to handle & wrap
procedural code in subroutines. In order to "create a new Person
record in memory in order to assign attribute values" one might write

person = new PersonRecord; // or more commonly, person = new Person;
person.lastName="Smith";

Then in order to write this to a file, you might write

person.write(personId);

or some such. Everything is like a subroutine except the main function
in the main class, which simply runs procedurally as one might expect,
running what are effectively subroutines from start to finish. It
reminds me of the first Fortran program that I made changes to on the
Pr1me, where almost every statement in it was a CALL.

Sure, I know there is a bit more theory, related to encapsulation,
inheritance, etc, but it all comes down to executing one big function
(application) that branches to subroutines from there. It can really
be quite useful to adopt at least some of the OO conventions IMO as
standards that help reduce the cost of on-going support (of course one
can also build OO systems that up the price of support too). When it
comes down to it, every function is procedural (start here, do this,
end here), whether written in an OO language, a procedural one, or
even a declarative one.

Just my two cents. cheers! --dawn

Quote:

Chandru"Dale" <dale_bened... (AT) flightcraft (DOT) ca> wrote in message

#25

Point well taken; OO comment over the top.

I just get tired of this "can't be fixed because we're too ill-trained to
modify PAL and we're afraid it'll break" BS. How on earth did the many Pick
systems programmers do it in the decades 68-85? Were they a different breed?
Can they take credit for being super-programmers? I mean, programs are
programs.

Chandru

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote

Quote:

On Apr 11, 5:44 am, "Chandru Murthi"
cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote:
It's been about 15 years, but, if memory serves, it ain't that hard to
do,
other experts to the contrary. No "rewriting' of the aql processor is
needed. very simply, the columnar line formatter uses a set of action
flags
to determine what to do on the next line. If, eg, a SVM is flagged, the
next
line consists of only SVM data. when all such data has been formatted,
the
SVM flag turns off, so we proceed with VM, if any. Etc.

So if a Translate returns mv's (or, for that matter, sv's,) pretty much
all
that has to be done is to , copy the data somewhere for safety and setup
the
standard register to the terminating delimiter (which is automatic
anyway.)
The AQL processer sees a VM and does its thing. You do need a flag to
return
to the "true" data stream. Takes about a week of work.

The real point, aside form all this detail is that we get this rubbish
that
it's hard to change the aQL processor (or practically anything else in
D3)
because Pick assembler is "hard". What a crock. Any average C program,
application or system level, gets to a level of obfuscation that far
exceeds
the simplicity of PAL. Not to mention object oriented code, which
requires a
level of concentration I, for example, could never possess.

I couldn't let this slide by for some reason. You might never wish to
code in OO, but I have no doubt you could muster up the concentration
as it doesn't take more than with traditional procedural (maybe even
less).

Data specified using OOP classes simply provides a spec for the schema
(a dict) such as PersonRecord or Person mentioned below, nothing that
would stretch your concentration levels, I'm sure. Additionally, to a
great extent OOP is just a standardized way to handle & wrap
procedural code in subroutines. In order to "create a new Person
record in memory in order to assign attribute values" one might write

person = new PersonRecord; // or more commonly, person = new Person;
person.lastName="Smith";

Then in order to write this to a file, you might write

person.write(personId);

or some such. Everything is like a subroutine except the main function
in the main class, which simply runs procedurally as one might expect,
running what are effectively subroutines from start to finish. It
reminds me of the first Fortran program that I made changes to on the
Pr1me, where almost every statement in it was a CALL.

Sure, I know there is a bit more theory, related to encapsulation,
inheritance, etc, but it all comes down to executing one big function
(application) that branches to subroutines from there. It can really
be quite useful to adopt at least some of the OO conventions IMO as
standards that help reduce the cost of on-going support (of course one
can also build OO systems that up the price of support too). When it
comes down to it, every function is procedural (start here, do this,
end here), whether written in an OO language, a procedural one, or
even a declarative one.

Just my two cents. cheers! --dawn

Chandru"Dale" <dale_bened... (AT) flightcraft (DOT) ca> wrote in message

#26

I truly don't have any inkling of how difficult the actual change
would be. If you have experience with PAL, then I accept your view.
But seeing as this change request has not been dealt with for such a
long time, I'm not holding my breath.

If my foggy memory serves me correctly, I believe that some 10 to 20
years ago, probably with AP, there was a release of Pick that brought
back the value marks. It was short lived (about 6 months), and I'm
not sure if AQL worked correctly with it.

As Tony G. says this is the most requested fix ever! I, personally,
have put in a request that RD, Pick Systems at the time, that the
TFile lookup should have some more options to allow backwards
compatibility, and still allow the newer options to bring back MV'd
data. So instead of TFILE;X;;3 the X could be another letter. Donno
if this is easy to do either.?.?.?

It is the lack of response in general from RD that is causing several
companies to re-evaluate their association with RD. Several times I
have waited months for patches to their system that I considered
critical.

OpenQM seems to have support that is just too good to be true. It
seems that it takes only days for fixes to be released. This is one
reason I'm researching the use of the OpenQM product. The licensing
fees are another big one.

Regards,

Dale

On Apr 11, 3:44 am, "Chandru Murthi"
<cmur_xyz_thi (AT) xyz_seeinggree_xyz_n (DOT) net> wrote:

Quote:

It's been about 15 years, but, if memory serves, it ain't that hard to do,
other experts to the contrary. No "rewriting' of the aql processor is
needed. very simply, the columnar line formatter uses a set of action flags
to determine what to do on the next line. If, eg, a SVM is flagged, the next
line consists of only SVM data. when all such data has been formatted, the
SVM flag turns off, so we proceed with VM, if any. Etc.

So if a Translate returns mv's (or, for that matter, sv's,) pretty much all
that has to be done is to , copy the data somewhere for safety and setup the
standard register to the terminating delimiter (which is automatic anyway.)
The AQL processer sees a VM and does its thing. You do need a flag to return
to the "true" data stream. Takes about a week of work.

The real point, aside form all this detail is that we get this rubbish that
it's hard to change the aQL processor (or practically anything else in D3)
because Pick assembler is "hard". What a crock. Any average C program,
application or system level, gets to a level of obfuscation that far exceeds
the simplicity of PAL. Not to mention object oriented code, which requires a
level of concentration I, for example, could never possess.

Chandru

#27

Chandru Murthi wrote:

Quote:

I just get tired of this "can't be fixed because we're too
ill-trained to modify PAL and we're afraid it'll break" BS. How on
earth did the many Pick systems programmers do it in the decades
68-85? Were they a different breed? Can they take credit for being
super-programmers?

Yeah! Works for me! =`;^>

--
frosty

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Dict CALL routine to return MV data

comp.databases.pick comp.databases.pick

Re: Dict CALL routine to return MV data - 04-09-2007 , 05:43 PM

Re: Dict CALL routine to return MV data - 04-10-2007 , 10:17 PM

Re: Dict CALL routine to return MV data - 04-11-2007 , 05:44 AM

Re: Dict CALL routine to return MV data - 04-11-2007 , 07:25 AM

Re: Dict CALL routine to return MV data - 04-11-2007 , 12:00 PM

Re: Dict CALL routine to return MV data - 04-11-2007 , 02:55 PM

Re: Dict CALL routine to return MV data - 04-20-2007 , 12:02 PM