× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



If you mean walk to the DS of a physical file saved in a save file using
SST:

1. Go to the savf *FILE space (type 19, subtype 01).

2. Roll forward to the system pointer to the Dump Space. It has a 'T'
after the hex data, and the last 2 bytes of the address are x1300 (type
of a Dump Space).

3. Use a P on the address to go to the Dump Space, and go to offset x1000.

4. Put P on the address there -- that takes you to the Dump Space data
record segment group.

5. The savf data recs start at offset x1000.

Once you get to the savf data recs, in the UNDEL2 utility at:

http://www.think400.dk/files/undel2.zip
or
http://dbg400.net/cgi-bin/twiki/view/DBG400/UndelVersion2

there's ILE RPG source code to find the DS in the savf recs -- pgm
UNDELM2, subroutine getds.


But if you mean walk to the DS of a physical file object on the system
using SST:

1. Go to the *FILE space (type 19, subtype 01).

2. Get the offset to the space data from the last 2 bytes on the 2nd row
(typically x100); call it FILspcloc.

3. Go to offset (FILspcloc + xE0). That's a system pointer to the first
member (type 0D).

4. Put P on the address in the system pointer and go to offset 0; that's
the member header.

5. Get the space offset from the last 2 bytes of the 2nd row as before
(typically x20), and call it MBRspcloc.

6. Put P on the space address at offset x18 to go to the mbr's
associated space.

7. At offset (MBRspcloc + x18) in the mbr's A.S. is a 4-byte binary
offset to the Lock List; call it LLoff.

8. At offset (MBRspcloc + LLoff + x20) is a system pointer to the Data
Space (type x0B).

9. Put P in the address in the DS system pointer and go to offset 0.
That's the Data Space header. At offset x17c is the 4-byte binary entry
length: record length + 1 (for the status byte), plus the length of
ALWNULL and variable-length field info; call it ENTLN.

10. At offset x118 in the DS header is the address of the segment table.

11. Put P at offset x118 to go to the segment table, which contains
16-byte entries. The first 5 bytes of each entry is the segment group
address of the data records segment group.

12. Put P in the first address in the segment table and go to offset 0.

13. At offset x20 is the default record. At ENTLN after that is the
first data record (RRN 1).

This is all on V5R3, but it should be similar on other releases.

Happy New Year!
--Dave

Vern Hamberg wrote:
Cool, Steve

You don't happen to remember how to walk to the data space in SST, do
you? Used to know onestuponatime when at IBM too many years ago - well
not so many as you and the TRW thing - heh!

Happy New Year
Vern

sjl wrote:
Vern wrote:
Each record has in the first byte in storage, the flag for whether it is
deleted. I think it has the value, in hex, of C0 or 80 but it has been a
while. The difference there is 1 bit, on or off.


Vern -

Having written numerous O_SH*T programs to retrieve deleted records from
files saved to save files (usually because some idiot deleted records that
should not have been deleted), active records have an X'80' in the first
byte, while deleted records have an X'C0' in the first byte.

The first such program that I wrote (in 1983, at a division of TRW in the
Dallas area) was a program that recovered our MAPICS source from a S/38
multivolume diskette backup where the last diskette of the multivolume set
had been overwritten by another library save (operator error, trying to
conserve diskettes...).

Our IBM SE used a 5280 data entry system to repair the last good diskette of
the backup and make it end of volume, and we were able to restore it as a
database file.

I ended up writing a program that parsed through the data byte-by-byte to
recover the source. Thankfully we had program listings for the program
source that was lost (on the last diskette, which had been overwritten). We
had to re-key the source for those programs from scratch.


- sjl










As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.