开云体育

Fish and everyone else. There is nothing wrong with Hercules or the tape. The issue is with PETAPE & CMS. Its documented on the VMSHARE link I posted. At some point the RDTAPE function was altered so

Mark A. Stevens wrote: Good! Then I'm out of here! :) Good to hear. "Call" me if you need me. :) (and by "call" I mean contact me via email of course. I have the ringer on my phone turned off

The tape is in this discussion groups Files section. I also use VM/370 CE 1.2 and it can be found at: http://www.vm370.org/VM/V1R1.2 ... Mark S.

Actually, it makes sense too. Because the first file is the abstract, and it lists all the files. Then typically one restore files on a case by case basis. So it does not matter there is no EOT mark,

I don't believe there is anything wrong with Hercules. This is a tape problem, which Rene has a solution for. I've successfully used VMFPLC2 to load numerous files to minidisks tonight. ... Mark S.

Fish wrote: [...] Or maybe there IS NO fix needed? Maybe things are working as designed (as expected, i.e. correctly)? After all, you did specify the "eot" option on your vmfplc2 scan command. --

Yes, I did just that with vmfplc2 and now everything works fine, no more error messages. :-) The tapes can be found in the Files section of this group. I personally used VM/370 CE 1.2. Cheers, Rene

René Ferland wrote: [...] Ah. Yes. That would certainly explain things. That's why Hercules got its EOF (End-of-File) error: there was no more data remaining on the tape! TAPEMAP essentially tried to

Mark A. Stevens wrote: [...] This error indicates "End of File". Hercules tried to read the tape, but there was no data to be read. The tape file was essential an empty file. Are you sure you attached

Thanks for the update. I have picked a few random ones that I am interested in, and they have loaded with no errors, and the results are all readable. I'll check on WATERLOO2.aws next. Not as

I think the error you get comes from the fact there is no EOT mark on the tape. After the last EOF tape mark, TAPEMAP tries to read the next and finds nothing, while (I think) it should detect an

Continued ... Attempt to scan the WATERLOO6.aws with PETAPE ... l petape module a ( date Filename Filetype Fm? Format??? Recs Blocks???? Date??? Time PETAPE?? MODULE?? A2? V?

I attached the WATERLOO6.aws tape to my VM userid and ran TAPEMAP. Below are the errors that showed up on the console. HHC01603I devinit 480 tapes/1982-05-25.WATERLOO6.aws HHC00221I 0:0480 Tape file

René Ferland wrote: [...] If AWSBrowse says it can read it okay, then it's okay. Which should NOT have fixed anything. The file should still be identical to its original contents. If you still have

René Very likely… http://vm.marist.edu/~vmshare/browse.cgi?fn=PETAPE <http://vm.marist.edu/~vmshare/browse.cgi?fn=PETAPE&ft=PROB&args=PETAPE#hit> &ft=PROB&args=PETAPE#hit probably won’t get time

*On Mon, Apr 1, 2024 at 08:59 PM, Fish Fish wrote:* *AWSBrowse does not report anything, so I'm assuming the tape is okay. I applied AWSFixTape anyway just in case. Yet an error still occurs while

Fish wrote: [...] Found it! It's called VTT2DISK. It's on one of the CBT tapes. Sam Golob wrote an article on it in some mainframe magazine as I recall. Just do a Google on "VTT2DISK" and you'll find

I have found various copies of WATERLOO6 and they all check out the same, via MD5sum . The date is the date of the ABSTRACT ABSTRACT file. abele_waterloo.aws is From Bob's distribution. WATERLOO6.aws

Quite by accident, I found that the DIFF MODULE dated 2009-06-06 on the VM/370 CE 1.2 Y disk comes from the 591 disk on the GCCCMS user, which is described in GCCCMS MEMO on its 191 disk as "*GCC

Harold Grovesteen wrote: Very old versions of Hercules itself could indirectly create such tapes. The problem (bug) would occur when a previously used tape file (i.e. a non-empty .aws/.het file) was