|
We have an MI application that does user defined screen IO. The UFCB definition looks like this: DCL DD UFCB CHAR(214) BDRY(16); DCL SPCPTR .ODP DEF(UFCB) POS( 1); DCL SPCPTR .INBUF DEF(UFCB) POS( 17); DCL SPCPTR .OUTBUF DEF(UFCB) POS( 33); DCL SPCPTR .OPEN-FEEDBACK DEF(UFCB) POS( 49); DCL SPCPTR .IO-FEEDBACK DEF(UFCB) POS( 65); DCL SPCPTR .NEXT-UFCB DEF(UFCB) POS( 81); DCL DD * CHAR(32) DEF(UFCB) POS( 97);/* RESERVED */ DCL DD FILE-NAME CHAR(10) DEF(UFCB) POS(129) INIT("PMSCREEN"); DCL DD LIB-ID BIN ( 2) DEF(UFCB) POS(139) INIT(-72); DCL DD LIBRARY CHAR(10) DEF(UFCB) POS(141) INIT("*LIBL"); DCL DD MBR-ID BIN ( 2) DEF(UFCB) POS(151) INIT(-73); DCL DD MEMBER CHAR(10) DEF(UFCB) POS(153) INIT("*FIRST"); /* LIB-ID AND MBR-ID ARE NEGATIVE TO SIGNIFY THAT NO LIBRARY */ /* AND MEMBER ARE SPECIFIED. */ DCL DD ODP-DEV-NAME CHAR(10) DEF(UFCB) POS(163); DCL DD ODP-DEV-INDEX BIN ( 2) DEF(UFCB) POS(173); DCL DD FLAGS-1 CHAR( 1) DEF(UFCB) POS(175) INIT(X'80'); DCL DD FLAGS-2 CHAR( 1) DEF(UFCB) POS(176) INIT(X'00'); DCL DD REL-VERSION CHAR( 4) DEF(UFCB) POS(177) INIT("0100"); DCL DD INVOC-MARK-CNT BIN ( 4) DEF(UFCB) POS(181); DCL DD MORE-FLAGS CHAR( 1) DEF(UFCB) POS(185) INIT(X'04'); DCL DD TAPE-END-OPTION CHAR( 1) DEF(UFCB) POS(186); DCL DD * CHAR(22) DEF(UFCB) POS(187); /* RECORD PARAMETER */ DCL DD RECORD-PARAM BIN ( 2) DEF(UFCB) POS(209) INIT(1); DCL DD RECORD-LENGTH BIN ( 2) DEF(UFCB) POS(211) INIT(5000); DCL DD NO-MORE-PARAMS BIN ( 2) DEF(UFCB) POS(213) INIT(32767); Occasionally we get an open failure for the display file and a big dump. Nine times out of ten the SEPT gets corrupted and we have to use SST to go fix it. The corruption is always in the same place. DUMP TAKEN FOR UNMONITORED ESCAPE MESSAGE .MESSAGE ID- CPF4182 .MESSAGE FILE- QCPFMSG LIBRARY- *LIBL .SEVERITY- 50 .MSGTYPE- 0F .SENDING- ..PROGRAM- QDMCOPEN LIBRARY- QSYS ..INSTRUCTION- 15D0 .RECEIVING- ..PROGRAM- PM0002V LIBRARY- PSSECURE ..INSTRUCTION- 0003 .MESSAGE- File PMSCREEN in library *LIBL member or device *N not opened. .MESSAGE DATA- 000000 D7D4E2C3 D9C5C5D5 4040D7D4 E2C3D9C5 C5D54040 5CD3C9C2 D3404040 40405CD5 *PMSCREEN PMSCREEN *LIBL *N* 000020 40404040 40404040 5CD54040 40404040 40400050 D6000000 00000000 00000000 * *N &O * 000040 80000000 00000000 D426DC45 340050A0 80000000 00000000 D426DC45 340050A0 * M üá &µ M üá &µ* Offset X'0060' in QINSEPT is the F.U. entry. .POINTERS- 000000 SYP 02 01 QT3REQIO 04 01 QSYS 3F10 0000 *PGM 000010 SYP 02 01 QWSCLOSE 04 01 QSYS 3F10 0000 *PGM 000020 SYP 02 01 QSFGET 04 01 QSYS 3F10 0000 *PGM 000030 SYP 02 01 QWSOPEN 04 01 QSYS 3F10 0000 *PGM 000040 SYP 02 01 QWSPBDVR 04 01 QSYS 3F10 0000 *PGM 000050 SYP 02 01 QWSRST 04 01 QSYS 3F10 0000 *PGM 000060 SPP 1A EF QPADEV0013TCHRI 484419 00004EA0 8000 000070 SYP 02 01 QSFCRT 04 01 QSYS 3F10 0000 *PGM 000080 SYP 02 01 QWSSPEND 04 01 QSYS 3F10 0000 *PGM 000090 SYP 02 01 QDCVRX 04 01 QSYS 3F10 0000 *PGM Now for the questions. Is the UFCB properly initialized? The way I interpret the S/38 Data Area manual is that the ODP and the NEXT-UFCB pointers should be initialized to NULL. Can you rely on these being set to NULL the first time a program is called? The problem seems to appear mostly toward the end of the day. The S/38 Data Areas manual also indicates that FLAGS-2 should be X'30' to indicate that we want to be open for reading and writing. Is this necessary? Other examples ( Leif's book @ http://iseries400.org <http://iseries400.org> ) initialize this byte to X'00'. Regards, Kurt Goolsbee +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.