Dict CALL routine to return MV data

#1

I have been told that D3 does not allow the return of MV data through
a dictionary call. Is this correct?

#2

dtsig wrote:

Quote:

I have been told that D3 does not allow the return of MV data through
a dictionary call. Is this correct?

No it separates it with spaces. Please be more specific.
MV, SV, etc.

Patrick, <;=)

P.S. Examples are good.

#3

On Mar 28, 7:53 pm, latimerp <"(latimerp)"@comcast.net> wrote:

Quote:

dtsig wrote:
I have been told that D3 does not allow the return of MV data through
a dictionary call. Is this correct?

No it separates it with spaces. Please be more specific.
MV, SV, etc.

Patrick, <;=)

P.S. Examples are good.

More specific than " .. not allow the return of MV data .."

I would think that MV would have given it away <G>

As for the space, that could be possible but

if i debug just before the return the return data looks like

*/RTNDATA *** BEGIN DIFF ***]L575]C190]IF
INVOICES.PRINT.DATE<1,1><=14131 THEN]IF
INVOICES.PRINT.DATE<1,1><=14265
THEN]*** END DIFF ***=

but when displayed it looks like

300 *** BEGIN DIFF ***
INVOICES.PRINT.DATE<1,1><=14131 THEN
INVOICES.PRINT.DATE<1,1><=14265 THEN
***

dict item looks like

001 A
002 0
003 Audit Source Archive Diff Rpt
004
005
006
007
008 CALL DICT.AUDITSOURCE.DIFF
009 T
010 50

Ideas?

thanks

#4

It is unfortunate, but I don't think a D3 call correlative will return
value-delimited data. (If someone knows a way around this, please
share!)

Typically, if the dictionary item's amc <2> refers to a multi-valued
field, then the call is executed once for each value in the list (you
can test access(6) in these circumstances to determine the position of
the value you are currently on, if necessary). This is why, when I
have a call correlative that needs to process an entire mv list, I
usually end up putting a 0 (zero) in field <2> of the calling dict
item and then reading the (mv) field I need via the access(3)
function.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

#5

On Mar 29, 10:55 am, "Scott Ballinger" <scott.ballin... (AT) gmail (DOT) com>
wrote:

Quote:

It is unfortunate, but I don't think a D3 call correlative will return
value-delimited data. (If someone knows a way around this, please
share!)

Typically, if the dictionary item's amc <2> refers to a multi-valued
field, then the call is executed once for each value in the list (you
can test access(6) in these circumstances to determine the position of
the value you are currently on, if necessary). This is why, when I
have a call correlative that needs to process an entire mv list, I
usually end up putting a 0 (zero) in field <2> of the calling dict
item and then reading the (mv) field I need via the access(3)
function.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Yeah .. i guessed that D3 was lacking but then I tried to do it with a
CALLR trigger .. to my surprise the trigger never fires <sigh> CallX
works great but CALLR nothing .. nada ..

Guess I will just have to sling more code instead of using access as
it should be used.

Thanks

#6

Dave:

I believe this is true. There is a fundamental difference between D3 and U2
in how they react to multi-values within a file. D3 is MV aware but loses
the MV delimeters when returning back to dictionaries. U2 isn't as MV aware
but it can (and must) return MVs to dictionaries. This means that when you
have an MV field

001 1]2]3]4]5

....and a dict

001 S
002 1

#7

On Mar 29, 5:20 pm, "Bill H" <n... (AT) nowhere (DOT) net> wrote:

Quote:

Dave:

I believe this is true. There is a fundamental difference between D3 and U2
in how they react to multi-values within a file. D3 is MV aware but loses
the MV delimeters when returning back to dictionaries. U2 isn't as MV aware
but it can (and must) return MVs to dictionaries. This means that when you
have an MV field

001 1]2]3]4]5

...and a dict

001 S
002 1
.
008 Call BP DoSomething

...the program "DoSomething" is called on each occurance of a value (5
times) in D3. This is what conversion codes do in U2 too, but not
I-descriptors (that's why it's sometimes said that the U2 products aren't
fully multi-value aware).

Consequently, in D3 one doesn't usually do things like manipulate a string,
or read MVs from a translated file, and return an MV string back to the
dictionary (it can't) but it's much easier to write a BASIC program to do
something on an MV field because the program runs on each value; while in U2
one has to process all values at once in the BASIC program with some kind of
loop and the result (usually MV) is returned.

...

Quote:

I'm not sure which is better. Hope this helps.

both -- and occassionally we need both!

if you want to allow dynamic data to be constructed/destroyed by the
subroutine... then U2's flavor can be more convenient. otherwise,
and MORE commonly -- if there is a one-to-one "persistent"
relationship between original value and some returned result, then D3
tends to become MUCH more convenient. IMHO

#8

Or, of course, one could simply *use whatever data* is returned by the
subroutine, (s)Vms included. So one could have the best of both approaches
and be fully intuitive. As Ultimate (now OSS) does.

Chandru

"dzigray" <google (AT) bridge2 (DOT) com> wrote

Quote:

On Mar 29, 5:20 pm, "Bill H" <n... (AT) nowhere (DOT) net> wrote:
Dave:

I believe this is true. There is a fundamental difference between D3 and
U2
in how they react to multi-values within a file. D3 is MV aware but
loses
the MV delimeters when returning back to dictionaries. U2 isn't as MV
aware
but it can (and must) return MVs to dictionaries. This means that when
you
have an MV field

001 1]2]3]4]5

...and a dict

001 S
002 1
.
008 Call BP DoSomething

...the program "DoSomething" is called on each occurance of a value (5
times) in D3. This is what conversion codes do in U2 too, but not
I-descriptors (that's why it's sometimes said that the U2 products aren't
fully multi-value aware).

Consequently, in D3 one doesn't usually do things like manipulate a
string,
or read MVs from a translated file, and return an MV string back to the
dictionary (it can't) but it's much easier to write a BASIC program to do
something on an MV field because the program runs on each value; while in
U2
one has to process all values at once in the BASIC program with some kind
of
loop and the result (usually MV) is returned.

..
I'm not sure which is better. Hope this helps.

both -- and occassionally we need both!

if you want to allow dynamic data to be constructed/destroyed by the
subroutine... then U2's flavor can be more convenient. otherwise,
and MORE commonly -- if there is a one-to-one "persistent"
relationship between original value and some returned result, then D3
tends to become MUCH more convenient. IMHO

#9

On Mar 29, 5:20 pm, "Bill H" <n... (AT) nowhere (DOT) net> wrote:

Quote:

Dave:

I believe this is true. There is a fundamental difference between D3 and U2
in how they react to multi-values within a file. D3 is MV aware but loses
the MV delimeters when returning back to dictionaries. U2 isn't as MV aware
but it can (and must) return MVs to dictionaries. This means that when you
have an MV field

001 1]2]3]4]5

...and a dict

001 S
002 1
.
008 Call BP DoSomething

...the program "DoSomething" is called on each occurance of a value (5
times) in D3. This is what conversion codes do in U2 too, but not
I-descriptors (that's why it's sometimes said that the U2 products aren't
fully multi-value aware).

Consequently, in D3 one doesn't usually do things like manipulate a string,
or read MVs from a translated file, and return an MV string back to the
dictionary (it can't) but it's much easier to write a BASIC program to do
something on an MV field because the program runs on each value; while in U2
one has to process all values at once in the BASIC program with some kind of
loop and the result (usually MV) is returned.

I'm not sure which is better. Hope this helps.

Bill

"dtsig" <d... (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?

<g> .. no ..it doesn't help <G>

Any MV product that cant return mv data is, in my opinion VERY
limited.

So instead of using access and other tools as I would hope to I will
just hack out some more code to get around the limitations of PICK.

Thanks Bill ..

#10

On Apr 2, 10:28 am, "dtsig" <d... (AT) hotmail (DOT) com> wrote:

Quote:

On Mar 29, 5:20 pm, "Bill H" <n... (AT) nowhere (DOT) net> wrote:

Dave:

I believe this is true. There is a fundamental difference between D3 and U2
in how they react to multi-values within a file. D3 is MV aware but loses
the MV delimeters when returning back to dictionaries. U2 isn't as MV aware
but it can (and must) return MVs to dictionaries. This means that when you
have an MV field

001 1]2]3]4]5

...and a dict

001 S
002 1
.
008 Call BP DoSomething

...the program "DoSomething" is called on each occurance of a value (5
times) in D3. This is what conversion codes do in U2 too, but not
I-descriptors (that's why it's sometimes said that the U2 products aren't
fully multi-value aware).

Consequently, in D3 one doesn't usually do things like manipulate a string,
or read MVs from a translated file, and return an MV string back to the
dictionary (it can't) but it's much easier to write a BASIC program to do
something on an MV field because the program runs on each value; while in U2
one has to process all values at once in the BASIC program with some kind of
loop and the result (usually MV) is returned.

I'm not sure which is better. Hope this helps.

Bill

"dtsig" <d... (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?

g> .. no ..it doesn't help <G

Any MV product that cant return mv data is, in my opinion VERY
limited.

So instead of using access and other tools as I would hope to I will
just hack out some more code to get around the limitations of PICK.

Thanks Bill ..

Bill, forgot to mention I thought I would trick the system by using
the CALLR trigger to generate the data for the record before use.
Imagine my surprise that CALLR does not appear to work <sigh> Oh
well .. sling that code <G>