RE: [U2] DATA Statements

2004-11-12 Thread Ken Wallis 
There's a UDT.OPTION which determines how DATA statements are processed.
You'll have to look up which it is.  I think the mnemonic is something like
PRIMEDATA - Prime and PICK behaved differently on this so UniData has an
option to control it.

Incidentally, there is no such thing as an 'MCD Flavor' (or even flavour)
UniData account.  UniVerse has 'flavors', UniData simply has whatever
behavioural switches you choose to set for each session, and most people set
them in the LOGIN.  There is ECLTYPE 'p' behaviour which can be switched on
for PICK style ECL syntax - DET-SUPP, COPY (O, etc, and there is BASICTYPE
'm' for McDuck behaviour in UniBASIC.  There are then numerous UDT.OPTIONS -
over a hundred these days.

Cheers,

Ken

Mark Johnson wrote:

 Are DATA statements accumulative until used?

 I see the following on a UD (MCD flavor) and it now appears
 to not work.

 Sequence in question:

 DATA X
 DATA Y
 EXECUTE RUN PROG ABC

 I usually would have

 DATA X:@AM:Y
 EXECUTE RUN PROG ABC
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] DATA Statements

2004-11-12 Thread Mark Johnson 
I don't dare mess with the UDT.OPTIONS on this system. It was installed
before me, I just do app programming and simplistically concluded that
things were set for MCD as PQN (real) procs work.

Thanks.
- Original Message -
From: Ken Wallis [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 12, 2004 3:12 AM
Subject: RE: [U2] DATA Statements


 There's a UDT.OPTION which determines how DATA statements are processed.
 You'll have to look up which it is.  I think the mnemonic is something
like
 PRIMEDATA - Prime and PICK behaved differently on this so UniData has an
 option to control it.

 Incidentally, there is no such thing as an 'MCD Flavor' (or even flavour)
 UniData account.  UniVerse has 'flavors', UniData simply has whatever
 behavioural switches you choose to set for each session, and most people
set
 them in the LOGIN.  There is ECLTYPE 'p' behaviour which can be switched
on
 for PICK style ECL syntax - DET-SUPP, COPY (O, etc, and there is BASICTYPE
 'm' for McDuck behaviour in UniBASIC.  There are then numerous
UDT.OPTIONS -
 over a hundred these days.

 Cheers,

 Ken

 Mark Johnson wrote:

  Are DATA statements accumulative until used?
 
  I see the following on a UD (MCD flavor) and it now appears
  to not work.
 
  Sequence in question:
 
  DATA X
  DATA Y
  EXECUTE RUN PROG ABC
 
  I usually would have
 
  DATA X:@AM:Y
  EXECUTE RUN PROG ABC
 ---
 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/

Re: [U2] DATA Statements

2004-11-12 Thread Timothy Snyder 
Mark Johnson [EMAIL PROTECTED] wrote on 11/12/2004 09:28:03
AM:

 I don't dare mess with the UDT.OPTIONS on this system. It was installed
 before me, I just do app programming and simplistically concluded that
 things were set for MCD as PQN (real) procs work.

Don't fear UDT.OPTIONS, embrace them.  Bear in mind that you're not
changing anything system-wide.  You're only impacting the session that
invokes them.  You can do some wonderful things by flipping these bad boys
on and off.

Tim Snyder
IBM Information Management
Consulting I/T Specialist , U2 Professional Services
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] DATA Statements

2004-11-12 Thread George Smith 
Tim,
Does that mean that if I am from the Pick background instead of
prime I can set the switch and it will have no effect on the new .NET
C# implementation. The docs recommend that you use the unidata
settings.

Thanks
grs

Don't fear UDT.OPTIONS, embrace them.  Bear in mind that you're not
changing anything system-wide.  You're only impacting the session that
invokes them.  You can do some wonderful things by flipping these bad
boys
on and off.

Tim Snyder
IBM Information Management
Consulting I/T Specialist , U2 Professional Services
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] DATA Statements

2004-11-12 Thread Brian Leach 
 Don't fear UDT.OPTIONS, embrace them.  Bear in mind that you're not
changing anything system-wide.  You're only impacting the session that
invokes them.  You can do some wonderful things by flipping these bad boys
on and off.

Yes, like create a support nightmare when someone forgets to reset the value
back again.

That's the really crazy thing about having such parameters set at runtime,
where they can modify the actions of all kinds of happily working routines
that someone chooses to run afterwards. Then support has to exactly
duplicate the entire chain of events that the user might have run, not just
one or two options. 

Always seemed a really bad idea to me.

Brian
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] DATA Statements

2004-11-12 Thread Timothy Snyder 
George Smith [EMAIL PROTECTED] wrote on 11/12/2004 10:56:00 AM:

 Does that mean that if I am from the Pick background instead of
 prime I can set the switch and it will have no effect on the new .NET
 C# implementation. The docs recommend that you use the unidata
 settings.

Not a problem.  You can set UDT.OPTIONS 2 ON (also accomplished with
ECLTYPE P) for your session without impacting what other users/processes
are doing.  There are also a ton of other options that can customize the
environment to make it more like what you're used to.  If there's some
behavior that isn't what you're used to, check the manual on UDT.OPTIONS -
there may be something there that will make you feel more warm and fuzzy.

Tim Snyder
IBM Information Management
Consulting I/T Specialist , U2 Professional Services
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] DATA Statements

2004-11-12 Thread Fred Finken 
While Ken's reply is absolutely correct, I would advise anyone to avoid the use 
of DATA statements. They work as advertised for simple applications, but they 
don't scale very well. Here's an alternative for interprogram communication 
that is easily understood, works well and scales well too.

Reserve the use of one of the user variables systemwide exclusively for this 
purpose. For example, @USER2. This dynamic array is available to all programs 
without requiring any kind of definition (like named common would). Field 1 of 
@USER2 will contain a multivalued list of titles for user defined variables. 
Field 2 will contain a related list of values for the user variables. You then 
write a few simple subroutines to manage the user variables. For example, 
SET.USER.VAR and GET.USER.VAR.

When program A wants to send a parameter to program B, it does this:

  CALL SET.USER.VAR(012345,SELECTION CUSTOMER)

Then when program B needs the parameter, it does this:

  CALL GET.USER.VAR(SELECTION.CUSTOMER,SELECTION CUSTOMER)

and optionally:

  CALL SET.USER.VAR(,SELECTION CUSTOMER)

This system makes it easy to define parameters on-the-fly and plug them into 
already running programs with a minimum of fuss. If anyone wants the source 
code, let me know.
-- 
___
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

[U2] DATA Statements

2004-11-11 Thread Mark Johnson 
Are DATA statements accumulative until used?

I see the following on a UD (MCD flavor) and it now appears to not work.

Sequence in question:

DATA X
DATA Y
EXECUTE RUN PROG ABC

I usually would have

DATA X:@AM:Y
EXECUTE RUN PROG ABC

Thanks in advance.
---
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/