I see two possibilities:
Either IAM is somehow managing to update the file in a way that doesn't
end up with the changed bit set for the file -- might possibly happen if
the file is never properly closed by the task that updates it-- maybe if
the file is opened for update the changed bit only gets set at close if
some write to the file actually took place..
or
some process is resetting the changed-bit after the file is closed but
before HSM migration kicks in for the dataset.
I believe there is a DUMPCLASS option to RESET the changed bits on files
on a full volume DUMP -- on the assumption that you want the changed bit
to only reflect changes that occurred after that backup dump to avoid
unneeded dumps for later incremental backups of the same volume. This
sounds like something you would definitely NOT want to specify on
volumes also subject to migration with FSM enabled. If FSM is enabled,
the changed bit being off tells HSM if it needs to migrate the dataset
and still has a previously-migrated version of the dataset that was
recalled but not yet deleted from its migration volume, that all it
needs to do to migrate is to change the inactive old migrated dataset to
active status, delete the live dataset, and point it do the old migrated
copy. So a sequence of recall dataset, update dataset,
somehow-not-set-or-reset-change-bit, migrate-with-FSM-enabled is
guaranteed to lose the updates after the recall.
Recalled, inactive migration versions of datasets on ML2 volumes can
persist for many weeks depending on the RECYCLE threshold for the ML2
volumes.
Joel C. Ewing
On 3/6/23 11:07, Dave Jousma wrote:
All,
We just learned that we have a problem with IAM (Innovation Access Method) the
high perf replacement for VSAM. No idea how long it has been going on, and I
have tickets open with both BMC and IBM on this. Seems to only affect IAM
files, and exists in both z/OS V2.4, and V2.5, and multiple versions of IAM.
We are currently at 10.x, but the problem occurs in V9.x as well. We see the
problem mostly in our Development space, not in PROD (or nothing reported yet,
but problem exists there too). We dont migrate much in PROD, and is why we
havent had the problem reported there.
The scenario here is
- existing IAM file gets updates, records added or updated, doesnt matter.
- file goes unreferenced for 7 days, so HSM migrates
- file gets recalled, the updates that were made are gone.
In HSM we do have FSM enabled (Fast Subsequent Migration), where if HSM is
called to migrate the dataset, and it hasnt changed since last migration, it
just deletes the dataset and reconnects it to the already migrated version in
HSM.
We've learned that turning FSM off circumvents the problem. IBM tells us that "HSM
checks the DS1RECAL and DS1IND08 flags in the Format-1 DSCB of a data set to determine if
a data set is eligible for fast subsequent migration. The DS1RECAL flag is used to
indicate if a data set has been recalled and the DS1IND08 flag is used to indicate if a
data set been modified since it was last recalled. "
IBM doc seems to indicate that OPEN handles setting these bits, BMC support
says they arent messing with these bits. I dont know *who* is to blame.
I'd be curious to hear from other installations that use IAM, has HSM with FSM
turned on.
The recreate scenario is (assumes new test file) with FSM turned on
1 - Allocate test IAM file and add a record easily identifiable
2 - HSM Migrate the file
3 - HSM Recall the file
4 - RECORD ADDED IN #1 is there.
5 - Add another record with new identifiable info
6 - HSM migrate the file.
7 - HSM Restore the file.
8 - Record from #1 is there, record from #4 is not there.
With FSM turned off, the dataset gets fresh migration copy every time, so the
issue is masked.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
