PROC problems

[MAV]

Hello Martin

We have the following programmes and procs:

Program CONTROL:
**********
CLEAR
PRINT "CONTROL"
CLA=2
PROCWRITE CLA
END


PROCS PASS:
**********
PQ
HRUN PROGRAMAS CONTROL
P
IF A = 1 G 1
IF A = 2 G 2
IF A = 3 G 3
1 CCCCC
O 1
X
2 CCCCC
O 2
X
3 CCCCC
O 3
X


MD PASS:
**********
PQ
(PROCS PASS)


MD GOPASS
**********
PQ
S2
(PROCS
A


In QM, when we execute "PASS" and "GOPASS PASS", output is:

:PASS
CONTROL
2
:
:GOPASS PASS
CONTROL
1
:

In D3 we obtain a different result with the same programmes and procs:

:PASS
CONTROL
2
:
:GOPASS PASS
CONTROL
2

What can we change in MD "GOPASS" to get the same response that the
one we obtain in D3?

Thanks in advance

Marcos Alonso Vega
INGESCO Sistemas Informáticos, S.L.

[Martin Phillips]

Hi Marcos,

I think that we need some help here as the Proc documentation doesn't
explain this very well.

What is happening is that when PASS runs from the GOPASS Proc , the current
pointer in the input buffer is pointing at field 2 whereas it looks like it
is 1 on D3.

I suspect that PROCWRITE is supposed to rewind the pointer to the start of
the buffer but I cannot find any reference to this in the D3, UniVerse,
mvBase or Reality documentation.

Am I right? If not, what should be happening?

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200

[MAV]

Hi Martin.

> I suspect that PROCWRITE is supposed to rewind the pointer to the start of
> the buffer but I cannot find any reference to this in the D3, UniVerse,
> mvBase or Reality documentation.

Juan (Arcoinet) has proposed this modification that we solve the
problem:

PROCS PASS:
**********
PQ
HRUN PROGRAMAS CONTROL
P

S1 (set the input buffer pointer)

IF A = 1 G 1
IF A = 2 G 2
IF A = 3 G 3
1 CCCCC
O 1
X
2 CCCCC
O 2
X
3 CCCCC
O 3
X

With this modification, the output is the same in D3 and QM.

Thanks,

[Simon Verona]

---------------------------------
Simon Verona
Director
Dealer Management Services Ltd

Sent from my iPhone

[Tony G]

I've checked docs for five platforms and only Caché mentions
resetting the buffer pointer. Different from all other
platforms, note that jBase and Caché use @AM rather than space as
the buffer delimiter ... maybe because Jim wrote both
implementations? ;)

Martin, I understand your thinking on this (don't change the
buffer unless the developer says so explicitly) but here's how I
think the other platforms see it. The base assumption is that
ProcWrite will overwrite the entire input buffer. If you're
pointing to a value in A3 now and you overwrite the entire
buffer, that value is no longer there - do you really want to
keep pointing at the same field? I'm also thinking a pre-set
pointer to a position beyond the end of buffer could result in
issues, depending on how each platform has it coded. While going
back to A1 may not be the preferred behaviour in all cases, it is
the commonly accepted default. I recommend resetting the QM
buffer to A1 on execution of ProcWrite.

It should also be noted that ProcRead assumes the entire input
buffer is present, not just the buffer starting with whatever is
set with Sx. So here again A1 seems to be a good default.

Marcos, your fall-through logic may be what you intend, where an
undefined value defaults to '1'. But in many cases that's not
what you'd want to do. This is why you hit "O 1" at label '1'.
I know this was just a sample case, but if your code does that
too, personally I'd modify that to return something like 'Invalid
Selection'.

HTH

Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!

[sdavmor]

I concur with Tony on all points.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory music project: <www.systemstheory.net>
on MySpace: <www.myspace.com/systemstheory>
on GarageBand: <www.garageband.com/systemstheory>
on Last FM: <www.last.fm/music/Systems+Theory>
on CDBaby: CDBaby <www.cdbaby.com/all/systemstheory>
get "Codetalkers" *free* at <www.mikedickson.org.uk/codetalkers>
NP: nowt

[Simon Verona]

Oops... Always remember to "lock" your iphone after reading emails but before putting phone in pocket! 

My apologies for the blank posts!

Simon

[eppick77]

Tony,

Reality also uses @AM as the buffer delimiter in PROC.

Eugene

[MAV]

Hi Toni

The example was just a test proc to isolate a problem that we found
during the conversion of an application.

Marcos Alonso Vega
INGESCO Sistemas Informáticos, S.L.
>

[Martin Phillips]

Hi Tony et al,

> Reality also uses @AM as the buffer delimiter in PROC.

This is one of the differences between PQ and PQN type Procs. QM supports
both (and PQX though I don't know where that originated).

We will modify PROCWRITE to reset the buffer pointer. Tony's logic as to why
this is the right thing to do is sound even if this behaviour is not
documented.

Martin

[Martin Phillips]

Hi all,

This fix will be in release 2.9-7 (soon but no date set). It will be
necessary for programs that use PROCWRITE to be recompiled.

If necessary, a pre-build of the compiler can be provided for users of
release 2.9-6.

[Dave Taylor]

Thank you to Marcos, Eugene, Tony, Martin and others who boiled this
application level problem down into a simple set of test processes and then
defined the problem.

I think that one of our applications has suffered from this issue also but I
have not been able to define the problem so succinctly.

I'm looking forward to the release of 2.9-7 to see if it resolves our issue
also.

Thanks to all,

Dave

Dave Taylor
Sysmark Information Systems, Inc.
Authorized IBM Business Partner
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com

[Dave Taylor]

Hi Martin,

I notice that Release 2.9-7 is now available on the website for download.

Did I miss the announcement of it's availability?

Is the PROC fix for Pick compatibility in this release?

Thanks,

Dave

Dave Taylor
Sysmark Information Systems, Inc.
Authorized IBM Business Partner
49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com
----- Original Message -----
From: "Martin Phillips" <martinp...@ladybridge.com>
To: <ope...@googlegroups.com>
Sent: Tuesday, September 15, 2009 4:36 AM
Subject: Re: PROC problems


>

[Martin Phillips]

Hi Dave,

> I notice that Release 2.9-7 is now available on the website for download.
>
> Did I miss the announcement of it's availability?

We (foolishly?) chose not to do a release email for this version as it
is relatively minor and we expect to release 2.9-8 fairly soon with
some new features that didn't make it into 2.9-7.

> Is the PROC fix for Pick compatibility in this release?

The PROCWRITE problem is fixed in 2.9-7 but you will need to recompile
programs that use this statement.


Martin Phillips, Ladybridge Systems

[Dave Taylor]

Maybe I'll wait for 2.9-8.

Thanks,

Dave

Dave Taylor
Sysmark Information Systems, Inc.

49 Aspen Way
Rolling Hills Estates, CA 90274
(O) 800-SYSMARK (800-797-6275)
(F) 310-377-3550
(C) 310-561-5200
www.sysmarkinfo.com
----- Original Message -----
From: "Martin Phillips" <MartinP...@ladybridge.com>
To: "OpenQM" <ope...@googlegroups.com>
Sent: Wednesday, October 07, 2009 1:58 AM
Subject: Re: PROC problems


>