Hi Joe,

You got the idea.

We have the first utility and change the library list of active jobs with a CL reading the library list table. The job descriptions that are connected to the library lists are used for starting new jobs.

That is historically grown. Maybe that the person who developed the utility did not know the QWDRJOBD API. The utility is old but younger than V2R2.

From my point of view using a second utility that retrieves the library list from a job description to update the library list of a running job is the better approach. Actually you do not necessarily need the " Library list entries " table, because you can always get the truth from the job description. This way the job description is the one and only source of information.

Accidentally I found the following article of Robert Cozzy that describes the second utility. Sadly rpgiv.com does not respond so that you cannot get the source code from there.

https://www.mcpressonline.com/programming/rpg/tips-and-techniques-use-jobds-to-store-library-lists

Regards,

Thomas.

-----Ursprüngliche Nachricht-----
Von: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxxxxxxxx] Im Auftrag von Joe Pluta
Gesendet: Samstag, 25. Januar 2020 20:29
An: wdsci-l@xxxxxxxxxxxxxxxxxx
Betreff: Re: [WDSCI-L] RSE library list problem

Thanks, Thomas!

I see two different "sub-utilities" here: one that maintains job
descriptions from a table, and the other that sets the library list from
a job description.  I have a client who already does the second one. 
The first one is interesting.  I would have really been able to use
that, because one project required that I modify every one of those job
descriptions, and it wasn't fun.  It wasn't difficult, but it was very
tedious.

So I'll continue to think about that.


On 1/24/2020 1:48 AM, Thomas Raddatz wrote:
Hi Joe,

I completely agree with you. The key is that I have to do a lot of ad hoc tasks, which often requires a different library list. I also do not want to write a CL for each of our utilities for settings up the library list.

Since you develop the RDi standards for your developers I may want to suggest the following idea:

1) Create a utility for maintaining library list stored in a table.
2) Create a job description for each of your applications and assign it to the library list created at step 1).
3) Let the utility of step 1) update the initial library list of the job description when the library list is changed.
4) Create a little program that uses the QWDRJOBD, format JOBD0100 to retrieve the library list of the job description for setting the current library list.
5) Call that program from RDi when connecting to the remote system.

The following ER model may help to get the idea in case I was unclear with steps 1) to 5):

+---------------------+
! Library list header |
! - name (id) !
! - description !
! - ... !
+---------------------+
! !
+---------------------+ +---------------------+
! Job descriptions ! ! Library list entries!
! - library ! ! - seq. number !
! - name ! ! - library name !
+---------------------+ +---------------------+

Regards,

Thomas.

-----Ursprüngliche Nachricht-----
Von: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxxxxxxxx] Im Auftrag von Joe Pluta
Gesendet: Donnerstag, 23. Januar 2020 19:50
An: wdsci-l@xxxxxxxxxxxxxxxxxx
Betreff: Re: [WDSCI-L] RSE library list problem

+100 for this.

I'm currently developing the RDi standards for our developers and I find
that to absolutely be the cleanest way to go.  Especially in conjunction
with Mike's note that you can have multiple connections.  We have
multiple enviroments on out machine and developers can literally have
dedicated connections for each environment.


On 1/23/2020 12:16 PM, Josée Labonté via WDSCI-L wrote:
I also use a CL in the "Initial command" And I add a parm to it which varies for each environment I have. The Cl will use the libraries necessary based on the parm.

One time setup, it works fine for me.

Josée



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