I have created a movement policy based on 4 groups (* GRP XXX).
I have 4 media in the IGNIFUGO location and a 5 media in location TAPMLB01, (all of this media using the MOVVER004 policy, which is the policy of 4 groups),
When I move this 5 media with the command MOVMEDBRM LOC (TAPMLB01), the move media to location IGNIFUGO.
In this moment I have 5 medias in location IGNIFUGO with the move policy MOVVER004.
I used the command to know the media that will be moved to location TAPMLB01, and insert these media in the tape library:
PRTMOVBRM SLTDATE (*BEGIN *CURRENT)
TYPE (* NEXT)
LOC (IGNIFUGO) , but it does not show me means.
If I execute the command MOVMEDBRM LOC(IGNIFUGO), I move a medium to location TAPMLB01, but I have not been able to insert it previously in the tape robot, and the BRMS inventory is out of square.
When inserting the medium, after executing the MOVMEDBRM command, the state of the medium in WRKMLMBRM MLB (TAPMLB01) remains in the *INSERT state.
I send you the spool of the configuration of the media movement that I use.
I also opened the case 62434,200,838, but in this case, I was using a duration movement policy * EXP:
Movement policy. . . . : MOVMEDI
Initial location . . . . . . : * SYSPCY
Use the container . . . . . : *DO NOT
Verify movements. . . . . : *DO NOT
Calendar of working days. : *EVERYDAY
Calendar of more days. . . . : *EVERYDAY
Move marked for duplication: * NO
Text . . . . . . . . . . . : Media Movement
Sec. Location Duration Container action
10 IGNIFUGO * EXP
It is important to be able to have a report of the media that will be inserted before relaying the movement:
PRTMOVBRM SLTDATE (*BEGIN *CURRENT)
TYPE (*NEXT)
LOC (IGNIFUGO),
in order to insert the tapes physically into the tape robot, and then execute the MOVMEDBRM command. In this way the state of the medium within the exchange library from "*INSERT" to "*SHARE400" , on the other hand if the operation is directly related to the MOVMEDBRM, without having inserted the tapes, I find that the inventory of BRMS is out of square indicating the product BRMS tapes in your inventory without having inserted them, and that the state of the medium in the tape library would not change me to "*SHARE400" and they remain in state "*INSERT", since the medium would be inserted after the execution of MOVMEDBRM.
Greetings.
Use Case: Different executions of the PRTMOVBRM command, with the result of the number of moving media:
PRTMOVBRM SLTDATE(*BEGIN *CURRENT) TYPE(*NEXT) LOC(IGNIFUGO)
Miembro QA1AMM del archivo QA1AMM en QUSRBRM abierto.
Se ha creado el informe QP1APVMS con 0 entradas.
Miembro QA1AMM del archivo QA1AMM en QUSRBRM cerrado.
PRTMOVBRM SLTDATE(*BEGIN *END) TYPE(*NEXT) LOC(IGNIFUGO)
Miembro QA1AMM del archivo QA1AMM en QUSRBRM abierto.
Se ha creado el informe QP1APVMS con 59 entradas.
Miembro QA1AMM del archivo QA1AMM en QUSRBRM cerrado.
The spool that indicated 59 means, makes reference to all the systems of network of BRMS, that are using like retention versions, I am only going to be based on the system LLURIA.
In this case, the PRTMOVBRM would be telling us that all means must be moved, but really with the MOVMEDBRM not all move, but those that are expired, also in this case there is also an expired means that the PRTMOVBRM mandate does not contemplate, since it seems that with media that use retention versions in the media policy, it does not contemplate it.
In this way, I will never be able to know the means that are being used as retention of media type versions, which means will be moved with the report PRTMOVBRM before relaying the MOVMEDBRM.
SELECT TMCVSR, TMSYID, TMCNXT, TMCSMD , TMMPOL , TMFILG , TMCEXP
FROM QUSRBRM/QA1AMM WHERE
TMFILG = 'MENSUAL' AND TMSYID = 'LLURIA'
Volume System Next Scheduled Move File Expiration
Serial ID Location Move date Policy Group Date
Number Name
D00040 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00044 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00054 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00059 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00097 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00072 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00058 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00026 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00080 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00083 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.190.409
D00082 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
D00090 LLURIA TAPMLB01 2.390.112 MOVVER011 MENSUAL 1.390.111
******** Fin de datos ********
WRKMEDBRM
Nº serie Fecha Fecha Fecha Clase Política de Conj Conj
Opc volumen Estado creación caduc Ubicación mover medio Sistema movimientos serie paralelo
D00083 *ACT 01/04/18 09/04/19 IGNIFUGO 05/03/19 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00026 *ACT 04/11/18 *VER 011 IGNIFUGO 05/11/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00040 *ACT 07/04/19 *VER 011 IGNIFUGO 08/04/19 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00044 *ACT 05/08/18 *VER 011 IGNIFUGO 06/08/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00054 *ACT 07/10/18 *VER 011 IGNIFUGO 08/10/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00058 *ACT 06/05/18 *VER 011 IGNIFUGO 07/05/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00059 *ACT 03/06/18 *VER 011 IGNIFUGO 04/06/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00072 *ACT 01/07/18 *VER 011 IGNIFUGO 02/07/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00080 *ACT 03/03/19 *VER 011 IGNIFUGO 04/03/19 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00082 *ACT 03/02/19 *VER 011 IGNIFUGO 04/02/19 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00090 *ACT 02/12/18 *VER 011 IGNIFUGO 05/12/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
D00097 *ACT 02/09/18 *VER 011 IGNIFUGO 03/09/18 ULTRIUM6 APPN.LLURIA MOVVER011 *NO *NO
The BRMS team does not intend to provide a solution to this request at this time, so it is being closed. This is being declined because of the low number of votes combined with a long list of higher priority items on the BRMS backlog which prevent us from getting to this item in a timely manner.
The CAAC has reviewed this requirement and recommends that IBM view this as a “nice to have” low priority feature. SMB clients are not likely to hit this problem often, but it may be more important for larger clients. Perhaps a new Locations parameter could be added to specify types of media allowed.
Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.
For more information about CAAC, see www.common.org/caac
For more details about CAAC's role with RFEs, see http://www.ibmsystemsmag.com/Blogs/i-Can/May-2017/COMMON-Americas-Advisory-Council-%28CAAC%29-and-RFEs/
Nancy Uthke-Schmucki - CAAC Program Manager
The BRMS team will use this request as input to planning but no commitment is made or implied. The request will be updated in the future if the request is implemented. The BRMS team will use votes and comments from others in the community to help prioritize this request.
The BRMS team has received the requirement and is evaluating it. The BRMS team will provide a response after evaluation is complete.
Attachment (Use case): Resutl SQL: SELECT TMCVSR, TMSYID, TMCNXT, TMCSMD , TMMPOL , TMFILG , TMCEXP FROM QUSRBRM/QA1AMM WHERE TMFILG = 'MENSUAL' AND TMSYID = 'LLURIA' And WRKMEDBRM to medis that haver Versions and politic movments *GRPXXX
Attachment (Description): Spool command PRTMOVBRM SLTDATE(*BEGIN *CURRENT) TYPE(*NEXT) LOC(IGNIFUGO)
Attachment (Use case): Spools command PRTMOVBRM SLTDATE(*BEGIN *END) TYPE(*NEXT) LOC(IGNIFUGO)