QTCPTMM/LOCKBOX takes a long time to ‘not’ save

15 pts.
Tags:
AS 400
BRMS
i5
iSeries
LOCKBOX
Save
During my BRMS save, I receive the following message; "/QTCPTMM/LOCKBOX cannot be saved". THIS is not a problem as the file is marked as 'Do Not Save'. My Problem is that the previous log entry has a time stamp of 23:09:05; the next entry, "LOCKBOX cannot be saved", has a timestamp of 06:25:48! The iSeries is taking 7 Hours and 16 Minutes to work out that this file should not be saved!! Has anyone else ever experienced this?


Software/Hardware used:
iSeries, BRMS, LOCKBOX, Save
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

First, ‘/QTCPTMM/LOCKBOX’ isn’t a file; it’s a directory. Not sure if that matters.

Second, BRMS is a product, so the vendor (IBM) probably needs to be asked about this.
Third, for us, we’ll need to know the general content of your /QTCPTMM/LOCKBOX directory, the overall configuration of your save request and the status of TCP/IP and SMTP in particular when the save runs. There might be other details needed later such as the number of SMTP e-mail users and an estimate of SMTP e-mail volume held in the system.

Discuss This Question: 2  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • dermoly1

    Thanks for your reply 'TheRealRaven'. First of all, I must apologize. After looking at the save's log file again, I saw that it wasn’t actually the directory LOCKBOX that was delaying the save for more than 7 hours but a directory called   /dev/null

     

    CPD37C3    20   14.07.18  23:09:25,838771  QSRSAV       QSYS        *STMT    QSRSAV      QSYS        *STMT

    Nachricht . . . :   /QTCPTMM/LOCKBOX kann nicht gesichert werden.

     

    CPD37C3    20   15.07.18  06:25:48,718550  QSRSAV       QSYS        *STMT    QSRSAV      QSYS        *STMT

    Nachricht . . . :   /dev/null kann nicht gesichert werden.

     

    It looks to me as though this directory is in use at the time of the save. I was just looking at the directory's attributes using the 'System I Navigator' (yes, I'm still using the 'old' version!) and although I obviously wasn’t able to see what was going on during the save itself, the directory at the moment has a status of 'In Use'. Read/Write jobs = 10, Write jobs = 9 and Read jobs = 4.

     

    If this is the case, that this directory was in use during the save, then how can I stop this happening again? All the subsystems are down at the time of the save but the IFS has nothing to do with them.

    Is there a command that I can execute before the start of the save in order to 'unlock' this directory? Unmount or something similar?

    Thanks for your help…

    15 pointsBadges:
    report
  • TheRealRaven
    I can't think of any reason that /dev/null would ever be saved. And after checking, I see that it has 'Can be saved=No' as an object attribute.

    This looks like a bug in BRMS, and I'd report it to IBM. But it also should be excluded from any save request.
    35,650 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: