× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



No, I would want IBM to allow me to propagate the "nullness" <g> of any
given value throughout my application. If I need to pass that field
into a subprocedure, should I also need to explicitly declare an extra
parm just so I can pass it's null flag? Ideally, null should just be an
attribute of the field, and implicitly passed along with its addressing
pointer.

Is a null attribute passed in OPDESC?

Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, October 14, 2008 2:58 PM
To: Midrange Systems Technical Discussion
Subject: RE: Interesting question and debate on ddl tables withdate
fieldsthatwill not always have a value

One - I don't see this as too tricky:
if %nullind(termDate);
dsply 'employee is active';
else;
dsply 'employee was terminated ' + %char(termDate); endIf; or any more
lines of code than if termDate = MichelangelosBirthday;
dsply 'employee is active';
else;
dsply 'employee was terminated ' + %char(termDate); endIf;

You do have some leg to stand on that if an incompetent programmer were
to check termDate without checking it's null indicator they can get into
trouble. For example if I do termDate = date(); // set to current date
%nullind(termDate) = *on; // set termDate off as employee is active
dsply termDate; // even though null, it will still display today's date
But, who's to say that same programmer wouldn't figure that a date of
0001-01-01 or Michelangelo's Birthday or whatever wasn't a valid date?

Were you hoping that IBM had written the compiler so that if you tried
dsply termDate; and if termDate was null then you'd get a messy MCH type
message as if you tried to dsply a variable that wasn't passed into the
program and you failed to check %addr on that?

I take it you also have an issue with
select termDate
into :termDate :termDateInd
from ....


Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/14/2008 03:04 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: Interesting question and debate on ddl tables with date
fieldsthatwill
not always have a value






So, are you saying that you use null support for all your business
applications? From the perspective of your users, would they ever be
able to tell the difference between an application using null support,
and an application using legacy techniques?

Seriously, my gripe is not the concept of null value, or even how SQL
processes in the presence of null values, but is about how hard (messy)
it is in a HLL like RPG. The reality is, if you MUST support null
capable fields in RPG, you must ALWAYS check the null indicator before
you EVER access the field in question. Did you know that even a null
field will still return a valid value during a fetch? It might be the
default initial value for that data type, or it might contain some other
value (assuming the field was set to null AFTER it had a value stored).


If IBM made null support more transparent, I would probably recommend it
usage. As it is, I don't think most developers would be disciplined
enough to always use it properly.

JMO,
Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Tuesday, October 14, 2008 1:02 PM
To: Midrange Systems Technical Discussion
Subject: RE: Interesting question and debate on ddl tables with date
fieldsthatwill not always have a value

Use nulls, that's what they're for!

Not to make this an state-of-the-nation discussion, but it's the very
fact that many people aren't willing to use the "current" stuff, that
makes an i look old. Imagine this question from an outsiders point of
view... the rest of the world uses null, to a SQL Server programmer this
wouldn't even be a question. Looking at an i, we'd see that we "can't"
use nulls, so i must be old! Granted, it's not that the i can't handle
them technically, but that our programmers can't handle them. Well,
sooner or later the programmers have to upgrade their skills, or guess
what, the machine IS old.

-Walden

--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Doug Palme
Sent: Tuesday, October 14, 2008 12:06 PM
To: Midrange Systems Technical Discussion
Subject: Interesting question and debate on ddl tables with date fields
thatwill not always have a value

I hope that subject description makes it clear. We are having an
internal
debate and discussion as we make the move towards sql tables and ddl
files; specifically using date data types.

An example, an employee file has two dates, HireDate and TermDate,
self
explanatory.....one is when the person is hired and the other is when
they
leave.

Obviously while they are an employee, they do not have a term date,
so how
do we handle that?

suggestions? comments? thoughts?

This transmission may contain information that is privileged,
confidential
and/or exempt from disclosure under applicable law. If you are not
the
intended recipient, you are hereby notified that any disclosure,
copying,
distribution, or use of the information contained herein (including
any
reliance thereon) is STRICTLY PROHIBITED. If you received this
transmission in error, please immediately contact the sender and
destroy
the material in its entirety, whether in electronic or hard copy
format.
Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.