I’m researching a problem with an OLD OLD (1988) NATURAL Report Mode program STORING a record on a VSAM KSDS; the DDM for this VSAM file includes a PE with 17 fields in the group, max 5 occurrences – the developers who noticed the problem SWEAR that this has always worked, until recently (though I am skeptical).
The STORE (partially) looks like this:
STORE LL-MFUPDATE WITH
DETAIL-SEQUENCE-NO(1) = 01
DETAIL-SEQUENCE-NO(2) = 02
DETAIL-SEQUENCE-NO(3) = 03
DETAIL-SEQUENCE-NO(4) = 04
DETAIL-SEQUENCE-NO(5) = 05
APPLICATION-NUMBER(1) = #TAPP-1
APPLICATION-NUMBER(2) = #TAPP-2
APPLICATION-NUMBER(3) = #TAPP-3
APPLICATION-NUMBER(4) = #TAPP-4
APPLICATION-NUMBER(5) = #TAPP-5 etc… etc… for the rest of the fields in the PE.
… … … …
END TRANSACTION
The resultant record in the VSAM file has all the occurrence 5 values ending up in occurrence 1 for all fields. Period. The other occurrences (2 thru 5) are empty. Occurrences 1 thru 4 are gone. I have verified (checked and double-checked) that the values in the source fields (immediately before the STORE) are populated and correct. We are running NATURAL 4.2.7 on z/OS. Any thoughts?
Could the DDM have been modified such that the “Maximum Occurrence” value (under Extended field editing) is now 1 instead of 5? Probably not else you’d get an error referencing occurrences 2-5 I bet.
I have never used Natural/VSAM, but I assume from the programming side it would be the same as Natural/Adabas. The use of the DDM provides a layer of extraction between code and database.
The only other thing would be… is it possible you have null values in occurrences 1-4 making occurrence 5 fall down to occurrence 1?
Hi Brian… Thanks for the reply. Hoope all is well with you. The DDM has not been modified in many years. And since this is a PE, even if there happened to be nulls going into other occurrences (which is not happening - the PE always gets 5 occurrences whenever a record is stored), the positionality SHOULD be maintained. I guess the real question is: Did something change in NVS427 that is causing this? I was hoping someone else would have seen something similar, but, alas, my searches have found nothing.
I submitted an incident to Support on-line just today. NAT427 went in about 2 months ago, before I started here. But the developer can’t swear to when the problem might have started. It’s a system that gets virtually no use over the summer, and has just begun to get some preliminary preparation for its busy season.
Made my own copy of the program, restowed it, made some changes, put in some probes, restowed again, etc, etc; same thing happens in all cases in DEV as well as PROD environments. Definitely consistent and reproducible.
Doug, DDM and Program attached. Note: Map is not attached, but WRITE in program verifies that all source fields are populated immediately before the STORE. In particular, occurrences 1 thru 5 (values are 01 thru 05 respectively) of DETAIL-SEQUENCE-NO are populated for every record, even if none of the other fields of the group have values. ‘05’ ends up in DETAIL-SEQUENCE-NO(1). LL_VSAM_Incident.docx (25.2 KB)
