RESTORE from BACKUP fails DB002300 C-4M353: DBIO Error:3010 Function:17

Products

• IDMS

Issue/Introduction

We have 2 CVs that can be started at R19 on z/OS but none of them has any application data yet. We are now trying to get a part of the application data through a different FTP configuration and it fails.

Probably due to the files getting not being transferred correctly via FTP. Below is an excerpt from the JOB output. 

Here is a sample of the error messages and how the dataset names look in the Job Output: 

CONNECT TO SYSTEM;
 Status = 0        SQLSTATE = 00000
 RESTORE SEGMENT MSTS,
                 SQIS BY AREA;
0UT015006 BACKUP file created on 2023-02-23-05.15.33.341895
 UT000038 Starting RESTORE of area MSTS.CARRIER-AREA
 Status = -4       SQLSTATE = 60002        Messages follow:
 DB002300 C-4M353: DBIO Error:3010  Function:17  Page:0:700001
 DB002504 C-4M355: Backup/Restore incomplete
1IDMSBCF  19.0                                      CA IDMS Batch Command Facility                               03/15/23   PAGE    2

à Ć©—@2GDATAB†000000IDMSR19¥

XÝ

0z
œ1440’ —    99999y
†Z60061s
œ   ^
00Þ
    0006M·
1
1Ú
 œ   

  “œm
BIGBKUP«
IDMSBCFi
    2048Klœ144000Ú
 œ   œ
  ˜œ >
STEPLIBã
SHR¢
SYSEVZ.IDMS.CV10.LOADLIBÚ
 œ   †
  œ >
 ã
SHR¢
„INSTALL.IDMS.R19GA.#[email protected]Ú
 œ   
  šœ >
 ã
SHR¢
INSTALL.IDMS.R19GA.#[email protected]Ú
 œ   —
  žœ >
    DCMSGã
SHR¢
€SYSEVZ.IDMS.CV10.SYSMSG.DDLDCMSGÚ
 œ     œ
>
†SYSPCHž Ú
 œ    

Probably due to the files getting not being transferred correctly via FTP.  

We did a BINARY transfer from VSE FTP to z/OS.  

You can see that the segment and area names are readable (i.e. the file was sent in binary mode – EBCDIC to EBCDIC).

 Here it is in hex:

BROWSE    SYSEVZ.IDMS.CV10.CV10B.BACK01   
 Command ===>                             
....IDMSUBKP2023-02-23-05.15.33.341895..A...    
FFFFCCDEECDDFFFF6FF6FF6FF4FF4FF4FFFFFF02C000    
FFFF944242272023002023005B15B33B341895041100    
 ------------------------------------------------
...ÚMSTS    CARRIER-AREA      ....ÀG..þ/...À....
FFFFDEEE4444CCDDCCD6CDCC44444400006C00A6000600F0
FFFE423200003199959019510000000000470AE100C400F8
 ------------------------------------------------
...ÚMSTS    MORDER-AREA       ....Xo..¢~...À....
FFFFDEEE4444DDDCCD6CDCC44444440000E9004A000600F0
FFFE423200004694590195100000000000760BA100C400F8
 ------------------------------------------------
...ÚMSTS    PRSIZE-AREA       ........,£...À....
FFFFDEEE4444DDECEC6CDCC4444444000000006B000600F0
FFFE4232000079299501951000000000000E0CB100C400F8
 ------------------------------------------------
...ÚMSTS    VEND-AREA         ........%....À....
FFFFDEEE4444ECDC6CDCC4444444440000010061000600F0
FFFE4232000055540195100000000000000D0CC500C400F8

 

Environment

Release : 19.0

Resolution

There was no problem with the FTP transfer, but rather the newly-created Database files just had not been formatted first. 

When  Restoring BY AREA the database Area/files must be formatted. 

When you issue a FORMAT command against a database file, IDMS/DB establishes space management pages (SMPs) for the area(s) that map to the file, initializes the space management entry for each database page, establishes a header and footer on each database page and sets all data portions of database pages to binary zeros

After formatting the files first the RESTORE from BACKUP to the newly-created database files was successful

Additional Information

IDMS 19.0 - Administrating - Allocating and Formatting Files