×
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.
 
  I can not see the context for the subject post [should it be a Re: 
subject?], so I expanded the subject... and I offer up some comment in 
case it might assist.
  Verify that all of the logical files over the file have at least one 
member.  As I recall, a row is output for a request to DSPFD 
TheLib/TheFile TYPE(*MBR) OUTPUT(*OUTFILE) even when the file has no 
members.  Because there is no member, the member name is blanks.  This 
is done because some details that are worthwhile [not very relational] 
for the file [that would be the same] across any member that could 
exist, if a member were to be added.  This anomaly must be coded around 
to avoid the condition, where the blank member name might be used to 
populate a variable for a command or program invocation; i.e. typically, 
just skip the row with a member name as blanks, when an actual member 
name is required for the function to be performed against a member.
  Hmmmm... or perhaps more likely possibility, now that I looked 
closer... is that the second DSPDBR is producing a row where the Library 
Name is blanks.  That is a valid transient condition, for CREATE or DROP 
of a logical file being performed under commitment control.  However 
there are known cases where the transient condition becomes accidentally 
permanent due either to a crash or a defect for which built-in recovery 
does not properly dispose of the tracking of the LF to the file or 
member.  Issue the DSPDBR MBR(named), DSPDBR MBR(*NONE), DSPDBR 
RCDFMT(named), and see if any unexpected blank values appear for the 
'Library' column of any row of information presented.
  But that looks unlikely too... given NEWOBJ() is more likely coming 
from a file name.?  Not sure... so again, by looking at the DSPDBR 
output [invocations noted above], review for an unexpected blank name in 
a file name.
  Note: there is a rename API which enables renaming an object to 
blanks [or effectively any potentially invalid name], albeit unlikely 
origin for this... or so I would guess.
Regards, Chuck
Rich Hart wrote:
Here is the relevant portion of my joblog:
                                                                                
  >> // AnzAccPth  NfuTrn                                                       
     No overrides exist at specified level.                                     
     3 records added to member QADSPDBR in file QADSPDBR in QTEMP.              
     1 records added to member QAFDMBR in file QAFDMBR in QTEMP.                
     1 records added to member QAFDMBR in file QAFDMBR in QTEMP.                
     1 records added to member QAFDMBR in file QAFDMBR in QTEMP.                
     1 records added to member QAFDMBR in file QAFDMBR in QTEMP.                
     End of file detected for file QADSPDBR in QTEMP.                           
     1 records added to member QADSPDBR in file QADSPDBR in QTEMP.              
     Value '          ' for parameter NEWOBJ not a valid name.                  
     Error found on RNMOBJ command.                                             
     Error found on RNMOBJ command.   
As an Amazon Associate we earn from qualifying purchases.