3

I have found and tested that the System/1, System/23, System/34, System/36 (all versions) and Displaywriter all use the same floppy format, from which I have found information at some ECMA documents.

However, it seems that inside they contain a second file system/database which is system-dependent. I would like to access files contained in System/23 floppies, therefore I am seeking information about IBM file systems and databases that could serve as a comparison.

Does anybody know where could I find that information?

Improve this question
5
  • Regarding the edit, That meaning is ard to see. Likewise does that mean /3, /360, /370 or /390 as well? After all, that "System/" moniker was for some time used all across IBM's offerings, from typewriters to mainframes. Also, asking for nest to the whole small IBM range would make this question way to wide, much like asking for anyone using MFM encoding. So it may help to restrict the question the just the system you're asking about (yes, /34 used the same BASIC/OS). Also noting exactly (links) what information you already have would be really helpful to anyone intending to answer. Commented Mar 7 at 13:49
  • Are you able to share disk images of the floppies you are looking at? It will be a lot easier for people to help you if you can give them something specific to work with. Commented Mar 8 at 1:56
  • In this post you can find the recovered files from a floppy disk: forum.vcfed.org/index.php?threads/… Commented Mar 8 at 10:39
  • I remember an S/32 which was related to S/34 and S/36 but not an S/23. Is that a typo? I'm pleased to see that S/38 is not in your list as, despite the similar name, it is very different. Commented Mar 12 at 14:28
  • As I was unable to locate images of floppies for System/38 and AS/400 I can't test if my program is compatible with them. No, System/23 is not a typo, but the first IBM computer ever to be based on an Intel microprocessor. Its developers later went on to develop the 5150 PC. Commented Mar 12 at 14:33

1 Answer 1

Reset to default
3

Have a look at the Diskette_General_Information_Manual, and see if you have some information in the volume (label VOL1, track 0, sector 7) and system application (label HDR1, track 0, sector 8) sectors.

The system application part should have a list of datasets.

At least that's how it is with the close-to-IBM-format floppies I have had access to.

If you have a dump of a particular floppy (or floppies), and could it put online so that we can have a look, that would also help.

So if I understand the thread on VCF correctly, you are trying to decipher the SYSLABEL and SYSDATA files.

For reference, the interesting part of some entries in SYSLABEL:

00000600:  02 00 f1 0f c2 4b c2 c9 c9 c1 4b c9 4b c9 e3 d4  ..1.B.BIIA.I.ITM
00000610:  c2 c1 d3 40 40 00 00 00 01 73 00 00 00 37 f0 f7  BAL  ....Ë....07
00000620:  00 00 00 00 00 00 00 00 00 02 00 00 00 00 01 00  ................
00000630:  00 00 00 00 01 0f 00 00 00 00 00 00 00 00 00 00  ................
00000640:  00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000650:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000660:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................
00000670:  00 a5 00 02 00 00 00 00 00 00 00 00 00 00 00 00  .v..............

00000800:  02 00 f1 0e c2 4b c9 c1 4b d9 4b d4 c1 e7 c9 d4  ..1.B.IA.R.MAXIM
00000810:  e4 d4 40 40 40 00 00 00 00 46 00 00 00 21 f0 f9  UM   ....ã....09
00000820:  00 00 00 00 00 00 00 00 00 01 02 00 00 00 32 00  ................
00000830:  00 31 00 00 00 00 00 00 00 00 00 82 09 16 00 00  ...........b....
00000840:  00 00 31 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000850:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000860:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02  ................
00000870:  00 a7 00 31 07 d8 00 05 00 00 00 00 00 00 00 00  .x...Q..........


00000a00:  02 00 f1 0e c2 4b c9 c1 4b d9 4b d4 c9 d5 c9 d4  ..1.B.IA.R.MINIM
00000a10:  e4 d4 40 40 40 00 00 00 00 4b 00 00 00 22 f0 f9  UM   .........09
00000a20:  00 00 00 00 00 00 00 00 00 01 02 00 00 00 32 00  ................
00000a30:  00 31 00 00 00 00 00 00 00 00 00 82 09 16 00 00  ...........b....
00000a40:  00 00 31 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000a50:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000a60:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02  ................
00000a70:  00 d8 00 31 07 d3 00 05 00 00 00 00 00 00 00 00  .Q...L..........

00000e00:  02 00 f1 0f c2 4b c1 d9 4b d9 4b d7 c1 e2 e3 4b  ..1.B.AR.R.PAST.
00000e10:  c4 e4 c5 40 40 00 00 00 00 21 00 00 00 22 f0 f9  DUE  .........09
00000e20:  00 00 00 00 00 00 00 00 00 01 02 00 00 00 4a 00  ..............[.
00000e30:  00 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .ñ..............
00000e40:  00 00 59 00 00 00 00 00 00 00 00 00 00 00 00 00  ..ß.............
00000e50:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000e60:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02  ................
00000e70:  04 fd 00 53 01 fc 00 06 00 00 00 00 00 00 00 00  .Ù.ë.Ü..........

and you already concluded that +2 is the type, +3 is the length of the name, and +4 is the name in EBCDIC.

This doesn't look like a partitioned data set at all (in particular if SYSLABEL is a sort of directory for SYSDATA). For reference, see DFSMS Using Data Sets p. 371ff to get an idea about partitioned data sets.

The use of EBCDIC 1, 2 etc. for the type of entry is very IBM-like, but the length of the name as a byte is already unusual (most IBM strings are just padded with space). Another candidate for an EBCDIC number is +0x1e in the entry, but the rest is binary, which is again unusual.

So my guess would be that this is some custom format for the System/23 Datamaster, and looking at other IBM formats is not going to help you.

The value at +0 seems to be either 02 or 00 (or maybe 02 00 and 00 00), so I'd guess that this is the number of sectors used for the entry. Also, the interesting differences seem to start around +0x6f, so that's where I'd look for the address information for the indexed file. If you have access to a working system, there should be some way to get at the contents of the particular file, so you can track which sector range(s) in SYSDATA a particular file corresponds to. With that information, one should be able to guess some addressing scheme.

I should also mention that according to information from the VCF thread this git repo has more floppy images, in case anyone else is interested in this.

Improve this answer
11
  • I have already surpassed the interchange format. I am able to extract anything related to this file system. However, just like a matroshka, there is a second file system on which I cannot break in to extract the data. I have been able to list the files, but nothing more. Commented Mar 8 at 11:40
  • Guess: That's a "partitioned dataset", and I actually searched for documentation on the internals and couldn't find any. I am not even sure if the format is the same for variants of the OS. Again, if you can link to the actual data, maybe we can help. Commented Mar 8 at 19:52
  • 1
    I am sorry, but I committed a huge mistake extracting SYSLABEL and SYSDATA. The sectors were scrambled and I wasn't reordering them. I have solved the issue and it is more clearer now. You can find the new files as well extracts in the following post: forum.vcfed.org/index.php?threads/… Sorry for the hassle. Commented Mar 10 at 9:25
  • 1
    Yes, I have located them. I have seen that in case of files of type 04 and 09 (both of record of type 1) the block length parameter inside the data block does not apply. Commented Mar 10 at 10:23
  • 1
    I have released my programs to extract the interchange format and the datamaster files at github. github.com/RetroAND/InterchangeFormatExtracter github.com/RetroAND/DatamasterExtracter Commented Mar 12 at 9:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.