Re: Shared member lock API

ð
Hello Ed,

You wrote:
>Thanks for the help.  You're right.  I was just looking in the list section.  
>Of
>course, this leads me to another question.  The file that is giving me the most
>difficulty is a multi-format logical file that is built over 8 separate 
>physical
>files.  While users will rarely have an object lock on the logical file, there
>will be numerous locks on each of the physical files, thus the origin of the
>shared member locks.

I don't agree with the last sentence.  Users of the logical WILL have locks on 
the 
logical file.  They will also have a lock on the logical member and as a result 
they will 
have locks on the underlying physical file members -- the so-called shared 
locks.  They 
WON'T have locks on the underlying physical file if they only access it via the 
logical.  
If they process the physical files directly they won't have any locks on any 
part of the 
logical (although they may hold seizes on the access path during key changes).

>The header section's shared file and library name identify only one of these
>physical files (from the manual - "When this field has a value, it applies to
>all entries in the list").  I assume it's not a coincidence that the file name
>is the first physical file listed in WRKOBJLCK's "Work with Shared Member 
>Locks"
>screen.  However, that screen allows you to see all of the physical files
>involved in the shared member lock by hitting Enter repeatedly.  I would like 
>to
>do the same with my program.  I tried reloading the user space with another 
>call
>to QWCLOBJL (using the same logical file name and library), but the shared file
>and library name did not change (I didn't think it would, but I tried it anyway
>just to make sure.).  Do you have any advice on that problem?

Firstly, calling any API a second time with identical information is unlikely 
to result 
in different data unless the API supports a *NEXT/*PREV parameter.

Secondly, don't assume that the information displayed by WRKOBJLCK and its 
subordinate 
displays is retrieved from a single source.  It is quite likely that IBM use a 
different 
interface from the API.  The API provides enough information to replicate the 
Work with 
Object Locks display and the Work with Member Locks display.

Replicating "Option 9=Work with shared member locks" requires you to find the 
information 
in another fashion.  The output from DSPFD shows a list of files and formats 
used by the 
logical file.  You could use this information and the member name from the 
OBJL0100 
format to list the locks for the shared member.  Investigate the database APIs 
or outfile 
support.  You may also wish to investigate the MATOBJLK MI instruction which 
provides raw 
access to similar information.

I hadn't considered the possibility of a logical built over different physical 
files in 
my earlier note.  That would suggest that the shared file name ought to be in 
the list so 
each member could have its associated file listed.  Perhaps you should complete 
a Design 
Change Request (DCR) to add an OBJL0200 format that does put the shared file in 
the list.  
It probably should also provide the shared member name since the current format 
doesn't 
show that either.  Besides, multi-format logical files don't fit the relational 
paradigm 
and were intended as a migration aid.  Why are they still being used?   :-)

You may have some fun if different underlying files have the same member name 
or if the 
underlying file has multiple formats but you can't expect to have everything 
solved for 
you.  What fun would that be?

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                       ð                        «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---