× 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.



That many transactions.  Their auditors are telling them to keep a certain
level of auditing turned on (SOX and CC info).  DASD is not an issue for
them.

Matt Graybiel
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
midrange-l-request@xxxxxxxxxxxx
Sent: Monday, September 05, 2005 11:22 AM
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 4, Issue 1665

Send MIDRANGE-L mailing list submissions to
        midrange-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
        midrange-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
        midrange-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MIDRANGE-L digest..."


Today's Topics:

   1. Re: NULL's on the Iseries (Marco Facchinetti)
   2. User queues (*USRQ) (M. Lazarus)
   3. AW: pgm that triggered the trigger pgm? (Hauser, Birgitta)
   4. Re: COMMON Orlando - (pnelson@xxxxxxxxxx)
   5. What happens when Jrn Rcvrs Hit 9,999,999,999? (Matt Graybiel)
   6. Re: What happens when Jrn Rcvrs Hit 9,999,999,999? (Don)
   7. Re: COMMON Orlando - (Al Barsa)
   8. Re: COMMON Orlando - (pnelson@xxxxxxxxxx)


----------------------------------------------------------------------

message: 1
date: Sun, 4 Sep 2005 10:03:34 -0700 (PDT)
from: Marco Facchinetti <facchinetti@xxxxxxxxx>
subject: Re: NULL's on the Iseries

Ok Vern, take this example and tell me if this is "support".

A PF like this (I use dates for null because are the most common null
fields):

field1    10A
field2      L   ALWNULL
field3    30A
field4      L   ALWNULL

when I use it in RPGIV the only thing I have to do is declaring in the H
spec ALWNULL(*USRCTL) and the use the biff %nullind to get or set the null
status. That's it.

In sql/rpg I have to do something like:

define e ds:

d myfile        e ds                  extname(myfilepf)
d indnul          s              4b 0 dim(1000)

prepare an sql statement:

wstring = 'SELECT * FROM MYFILEPF WHERE .....';
 /end-free
C/exec sql
C+  PREPARE S1 FROM :WSTRING
C/end-exec
C/exec sql
C+  DECLARE CURS1 CURSOR FOR S1
C/end-exec
C/exec sql
C+  OPEN CURS1
C/end-exec
C/exec sql
C+  FETCH CURS1 INTO :MYFILE :INDNUL
C/end-exec

Now to test if the two fields are null you have to to write something like:

if indnul(2) <> 0;
  do something...
endif;
if indnul(4) <> 0;
  do something...
endif;

Now try to modify the PF as follow:

field1    10A
field1A   50A
field2      L   ALWNULL
field3    30A
field4      L   ALWNULL

The code is still working?

And before you suggest not use SELECT * remember that you have to build and
maintaine the list of fields in the select statement and in the receiving ds
to follow all your database modifications (removing and adding fields) and
not just re-compiling as with RPGIV.
Since we where talking about support this is what I mean for almost not
supported.

HTH
Marco

--- Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:

> The NULL attribute of a column (field) is a bit flag stored in the record 
> ahead of the actual data. If you are working in C, you need to use a 
> NULL-indicator array. Same in RPG IV, and even in embedded SQL. The trick 
> is to have an array of 4B 0 (according to the manual) and append it to the
> 
> host variable array
> 
>   :hostarray:indarray
> 
> Then there is a value for each column that can be used to get or set the 
> NULL attribute. This seems like pretty full support for SQL/RPG, if by
> that 
> you mean embedded SQL.
> 
> Later
> Vern
> 
> At 02:41 AM 9/3/2005, you wrote:
> 
> >If you plan to use:
> >
> >SQL, the support is complete
> >RPGIV, partial support for previous release, good for V5R3
> >SQL/RPG, almost not supported.
> >
> >HTH
> >Marco
> >
> >P.S. RPGIV supports null only on database fileds.
> >
> >--- Chris Payne <CPayne@xxxxxxxxxxxxxxx> wrote:
> >
> > > Hello,
> > >
> > > What is your take on NULL's on the Iseries, do they have a place? If a
> > > user does not enter data into an optional numeric field, do you set
> the
> > > field to 0 or NULL? What are some of the drawbacks of using NULL's?
> > >
> > >
> > >
> > > Christopher M. Payne
> > >
> > > CPayne@xxxxxxxxxxxxxxx
> > >


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


------------------------------

message: 2
date: Sun, 04 Sep 2005 18:23:38 -0400
from: "M. Lazarus" <mlazarus@xxxxxxxx>
subject: User queues (*USRQ)

  Can anyone tell me how to use User queues (object type *USRQ) and how 
they are better / different than *DTAQs?

  Thanks.

  -mark



------------------------------

message: 3
date: Mon, 5 Sep 2005 09:48:43 +0200 
from: "Hauser, Birgitta" <Birgitta.Hauser@xxxxxxxxxxx>
subject: AW: pgm that triggered the trigger pgm?

Hi,

I still use a small CL-Procedure to determine the CALLER
(Program/Procedure), with SND/RCVMSG.

Depending on the action the database manager calls two different programs,
that perform the CALL to the trigger program.

These programs are:
QDBPUT for Input
QDBUDR for Update / Delete / Read

So I have only to pass one of these programs to my CL-Procedure as CALLED,
And get my original CALLER-Program/Procedure.

Birgitta

-----Urspr|ngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von
fkany@xxxxxxxxxxxxxxxxxx
Gesendet: Freitag, 2. September 2005 17:56
An: MIDRANGE-L@xxxxxxxxxxxx
Betreff: pgm that triggered the trigger pgm?


Does anyone know how to let a trigger program know which program triggered
it?  The program status datastructure didn't have that information.

Thanks,

Frank



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.