Rob - thanks for your comments:
First: Im not suggesting breaking JOBD and LIBL, I simply don't understand why they were bundled together way back when. They don't seem to have much to do with each other except for the fact that they are sometimes used simultaneously.
IBM bundled them together, but then sets the default on SBMJOB to ignore the LIBL associated with the JOBD (and use the current LIBL instead). It seems backwards. Like a double negative.
Second: I am not suggesting that IBM change the default of SBMJOB to INLLIBL(*JOBD). What a mess that would make.
Third: What gives you the impression that I don't read your emails? I appreciate EVERYONE'S suggestions from this forum and other places. It seems that the protocol here is to NOT thank people in general, although I do oftentimes thank people via the list or privately.
Yes I agree that asking "why doesn't IBM have their own RTVJOBD command" is a good question. But also wasted energy. I am guessing that this has been a lacking feature since s/38 days 30+ years ago and is not on anyone's radar at IBM to address.
It seems that maybe the cardinal rule of "don't use repeating fields" was broken with the JOBD/LIBL definition and has made it a bit difficult for IBM to provide the tools to report JOBDs.
Although the archaic single-level library structure in OS400 makes it a tough sell too (compared to every other OS today which has unlimited level "libraries").
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 09, 2013 6:33 AM
To: Midrange Systems Technical Discussion
Subject: RE: JOBD analysis
First: I suppose IBM could break up the job description into two separate
objects. Why would that make a difference? They could still use the same
command DSPJOBD to get the same spool file or display of the job
description. They could still use the same API to retrieve the same
information. The objects would not be physical files. So you still would
have to use the commands or APIs to get to it. Breaking it apart serves
no purpose.
You're asking the wrong question. What you should be asking is why
doesn't IBM have their own RTVJOBD command? And submit a DCR (or COMMON
requirement, providing the phase of the moon allows the website to work)
for such an animal.
Then it would be as simple as
step 1: DSPOBJD to generate a list of job descriptions
step 2: Process that list with RTVJOBD
While you're waiting, get really bold, learn something new. Write a
program that uses that API or use one of the many links that people posted
to code that uses that API.
Second: The default on SBMJOB is not *IGNORE. It's not even an option.
The default is *CURRENT, even on my 7.1 system. This is documented at:
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/sbmjob.htm
If you want it to use the library list of the job description then change
INLLIBL from *CURRENT to *JOBD.
I can guarantee you that IBM will never change that from *CURRENT to
*JOBD. Never. It would break too much existing code. You could change
your command default to use *JOBD but I strongly discourage that. If you
purchase a vendor package that assumes *CURRENT you will blow it up.
Third: Joel, I try really hard to give you complete answers yet I get the
impression that you never read them. Am I filtered out of your email?
Rob Berendt
midrange.com
