Re: SAVLIB & SAVCHGOBJ ... ** SOLUTION **

perhaps the trick would be to put the JOB on hold verses putting the DEVICE
on hold.

----- Original Message ----- 
From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, September 28, 2005 7:57 PM
Subject: Re: SAVLIB & SAVCHGOBJ ... ** SOLUTION **


>
> On 29/09/2005, at 1:13 AM, Douglas Handy wrote:
>
> > The only thing I did not understand in my testing is when doing ALCOBJ
> > *EXCL
> >> with a device, then putting the device on hold, it still shows that
> >> it is
> >> locked when doing DSPOBJLCK. But as long as the device is HELD it
> >> doesn't
> >> matter. it still saves the file.
> >
> >
> > Interesting -- is this also true of database files which are still
> > locked
> > when you hold an interactive job (and which are opened for update)?
> >
> > That is what I assumed was the major problem with your method -- that
> > the
> > objects would still be locked.
>
> I came to the same conclusion as you and was going to question the
> original premise. However when I saw your detailed append I waited to
> see what the original appender would say. The silence is interesting.
>
> I decided to test it for myself expecting that it would not work and
> what do you know I'm right. The steps I followed:
>
> 1) I signed on using PC5250 (normal user) on QPADEV000D
> 2) Ran command: UPDDTA SHC/ADRBOOKP
> - F11=Change
> - Page down (to lock a record)
> 3) Check locks on ADRBOOKP physical file
> - Two *SHRRD object locks on the file
> - Two *SHRRD locks on the member
> - Two *SHRUPD locks on the data
> 4) Signed on to another session as QSECOFR
> 5) CRTSAVF QTEMP/TEST
> 6) SAVOBJ ADRBOOKP SHC *SAVF SAVF(QTEMP/TEST)
> - Save timed out and failed with "Unable to allocate object" for
> ADRBOOKP
> 7) HLDCMNDEV QPADEV000D
> 8) SAVOBJ ADRBOOKP SHC *SAVF SAVF(QTEMP/TEST)
> - Save timed out and failed with "Unable to allocate object" for
> ADRBOOKP
> 9) SAVLIB SHC *SAVF SAVF(QTEMP/TEST) UPDHST(*NO)
> - 877 objects saved; 1 object not saved
> - Unable to allocate ADRBOOKP
> 10) WRKCFGSTS *DEV QPADEV*
> - Showed QPADEV000D with status HELD
>
> Then I thought what effect does the HOLD have on the job at device
> QPADEV000D? I tried doing things in the job. The job still showed
> UPDDTA displayed so I pressed F3 to exit, exit panel displayed. Pressed
> Enter, command entry displayed. SysReq 1 got sign-on display. Signed
> on. Signed off. All while the device still showed a status of HELD. So
> holding a device already in use has no real effect. It will stop the
> sign-on screen from being displayed if the user signs off. Holding a
> device already at the sign-on screen stops a user signing on.
>
> Thus the only advantage of HLDCMNDEV is that it stops a user signing on
> to a device that is held but it does nothing to help with a session
> that is already signed on. Perhaps this is where you and I made the
> same misinterpretation? If the original appender is simply interested
> in stopping new sessions from starting up then HLDCMNDEV will work.
> However if he wants to save objects in use (as it seems both you and I
> presumed) by an active session then HLDCMNDEV will not help.
>
> Interestingly PC5250 **KNOWS** when the host device is HELD. Start with
> a device at sign-on, type a user ID, the characters appear. Now erase
> the characters and hold the device. Now type. Hmm no characters.
> Release the device. The typed characters miraculously appear. That I
> will have to investigate further.
>
> Regards,
> Simon Coulter.
> --------------------------------------------------------------------
>     FlyByNight Software         AS/400 Technical Specialists
>
>     http://www.flybynight.com.au/
>     Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>     Fax:   +61 3 9419 0175                                   \ /
>                                                               X
>                   ASCII Ribbon campaign against HTML E-Mail  / \
> --------------------------------------------------------------------