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



Note that all of this code, including the Java, is running natively on
OS/400 and not on a PC or in a servlet container.

In the scenario the "client" or requester is the RPG program submitting
records to a single, concretely named, data queue - MYLIB/DQINPUT.  The
"server" or receiver is the Java program, running natively in OS/400,
listening to MYLIB/DQINPUT. The data queue record contains the name of the
data queue the Java program should respond to with it's results.  This
response data queue is what I am trying to name uniquely by job number
because the RPG program needs to ensure it only picks up its records, and by
having its own data queue I can ensure that.

[reading your last paragraph]
I guess I have never used a keyed data queue so I have some questions on
that.

Can my RPG program listen, and only be notified of a specific data queue
entry based on a key I specify? So I add another field to the DQINPUT data
queue record that sends in a UUID that I want it to use when it writes the
key in the response data queue?  This would rock because then I would only
need two data queues period.  After reading the following link I think I am
good to go with this method as it appears my RPG program will just wait for
entries with a specific key: http://tinyurl.com/kz4q3

You might even be able to get by with one data queue with the server using
it's own UUID.
I have two different "record formats", one for the input and one for the
output. Do I just make the data queue as long as the longer of the two and
then have a reserved area at the beginning that I check to see what format I
am dealing with? (i.e. a 10 char field with either a value of RCDFMT1 or
RCDFMT2)

Thanks,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, September 13, 2006 8:56 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Costly PSDS

Let me see if I got this right.  I may have the client and server names
reversed, but hopefully, other than that, the concept is sound.

You have multiple client jobs talking to one server job.

The client jobs all send data into one data queue for use by the server job.

The server job then sends data out to various data queues for use by each of
the client jobs.

Right?

Why not just use two data queues?  One for the server and one for all
clients?  And make the client queue a keyed data queue?  And each spawned
client job could generate it's own UUID.  Send that along with the data
request to the server data queue and then the server data queue could write
to the client data queue with the UUID as the key.

You might even be able to get by with one data queue with the server using
it's own UUID.

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





"albartell" <albartell@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
09/13/2006 09:42 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Costly PSDS






What about using the file function that creates a file with a random 
name,
then retrieve that name and use it as the name for the new data queue.

You have my ear, what's the specific function name? :-)


Also why not just create it in QTEMP so that it goes away with the job?

I need to have a program (Java) in another job write to this uniquely 
named
response data queue.  If it resides in QTEMP I don't think the other job 
has
access to it, correct?

Also Rob, you mentioned creating a UUID.  The only problem is that most 
will
not be able to fit into 9 characters (assuming first character will need 
to
be specified by me and be non-numeric).  That is why I am looking to use
something like JOB_NUM from PSDS (but it sounds like that might be
dangerous).

Aaron Bartell
http://mowyourlawn.com



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Bob Cozzi
Sent: Wednesday, September 13, 2006 8:32 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Costly PSDS

Aaron,
What about using the file function that creates a file with a random name,
then retrieve that name and use it as the name for the new data queue. 
Also
why not just create it in QTEMP so that it goes away with the job?

-Bob Cozzi
www.iSeriesTV.com
Ask your Manager to watch iSeriesTV.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of albartell
Sent: Wednesday, September 13, 2006 7:44 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Costly PSDS


The data queue that is receiving the initial input will be "system wide"
because I will have a prestarted Java job out there waiting on that data
queue to pick them up and process them from any number of jobs.  So that 
can
be named DQIN for all intents and purposes.  The data queue the Java 
program
is responding to is the one that will need to be unique to the job. 

So that leaves me needing to create system wide uniquely named data 
queues.
Note though that it only has to be unique within the job because after it 
is
initially created (using the JOB_NUM as part of the name) I can reuse it 
and
not recreate it each time.  I can understand your concern about job 
numbers
going full circle, but I should be able to rely on the fact that the same
job number will never be active at the same time and based on that, as 
long
as I "initialize" the job number data queue at program startup time I 
should
be good to go.

This is where it would be nice to have a "destructor" routine in RPG that 
is
called when a program is ended because I am trying to figure out how to
cleanup the data queues unique to each job.  Sure I can code a routine 
that
the programming calling me can call when the user exits out of their
interactive app in a controlled fashion (i.e. hitting F3), but what is a
best method to cleanup when the user simply closes their 5250 emulation
window?

Thanks for your tangent Rob, it is helping me be sure of the direction I 
am
taking :-)

Aaron Bartell
http://mowyourlawn.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Monday, September 11, 2006 9:34 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Costly PSDS

Going off on a tangent.  But if the data queue is used ONLY by that job, 
why
not create it in QTEMP and not worry about the data queue name?

If it is used by multiple jobs (and unless you a thread coding animal I
suspect it is) then you need to consider "truly unique".  Being as a data
queue program can run until the next IPL, and if you fire off enough jobs
between IPLs then your job number could be reused.  Maybe use UUID 
instead?

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




--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, 
or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-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.