¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 ¿ªÔÆÌåÓý
  1. H390-MVS
  2. Topics

help with restoring a dasdi dump/restore tape

 

I have a file, fairly old, that looks like it is a DASDI dump restore tape.? It is clearly an EBCIDIC tape.? I am not even sure what is on it as I probably received this in the late 1990's.?

I would like to restore it, if possible.? I'm guessing it is a dump of a 3330, but I don't know an do not know enough about the format of a DASDI dump/restore tape to figure it out.? Also I'm not sure what format it is in as the filetype says TAP.

So, how do I mount this on Hercules?? Just like any other tape (het or aws) or something else.

I'm presuming that once I get it mounted TAPEMAP will help me figure out what is on it and what DASD volume type I need to restore it.

If it is a DASDI dump tape, I guessing I can just IPL from it and restore it to DASD as I would have years ago, but that may not be a correct/best approach in this instance.

Guidance will be appreciated.

By the way here is a png of the first part of the file.

Thanks,
?- Mark

Hexfiend window of tape.png

 

Try ?
Not sure if XMIT Manager would handle it.

On Tue, May 14, 2024 at 4:49?PM mspitz via groups.io
<mspitz@...> wrote:

I have a file, fairly old, that looks like it is a DASDI dump restore tape. It is clearly an EBCIDIC tape. I am not even sure what is on it as I probably received this in the late 1990's.

I would like to restore it, if possible. I'm guessing it is a dump of a 3330, but I don't know an do not know enough about the format of a DASDI dump/restore tape to figure it out. Also I'm not sure what format it is in as the filetype says TAP.

So, how do I mount this on Hercules? Just like any other tape (het or aws) or something else.

I'm presuming that once I get it mounted TAPEMAP will help me figure out what is on it and what DASD volume type I need to restore it.

If it is a DASDI dump tape, I guessing I can just IPL from it and restore it to DASD as I would have years ago, but that may not be a correct/best approach in this instance.

Guidance will be appreciated.

By the way here is a png of the first part of the file.

Thanks,
- Mark


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
 

I'm not familiar with that file format, but ESD and TXT records are found in program load modules.

Given that there are no obvious Tape Header records, I suspect you are correct in assuming it's an IPL'able tape.

Regards
--?
¦Ó¦Ò³¾
 

Then transfer it to a host machine, use suffix AWS, Start Hercules,
mount IPL from tape, mount the dataset. Usually named by the VolSer
in the first 6 bytes of the Standard Label.

On Tue, May 14, 2024 at 5:26?PM botongrui, aka ¦Ó¦Ò³¾. via groups.io
<botongrui@...> wrote:

I'm not familiar with that file format, but ESD and TXT records are found in program load modules.

Given that there are no obvious Tape Header records, I suspect you are correct in assuming it's an IPL'able tape.

Regards
--
¦Ó¦Ò³¾


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
 

Thanks all.? I will try it tonight.? I just wasn't sure what suffix to use.

I'll post what I find out.

?-Mark
 

Hi Mark,

From the image you have provided you have a standalone DUMP/RESTORE tape.

It is an unlabelled tape where the first data set is the IBM standalone utility program IBCDMPRS. For ease of IPL loading this program is written on the tape as unblocked 80-byte records. Following the tape mark there will be a second data set which will be a dumped DASD volume. ?

In the usual mode of operation you would IPL from the tape, loading the IBCDMPRS/DUMPREST program into storage. Next step would be to generate an interrupt on a 1052 console device and key in DUMPREST control statements. These are described in GC26-3902 MVS Utilities.

However, if you have a running MVS system then the IEHDASDR utility program can restore the DASD volume with an MVS job as the format used by IBCDMPRS to dump a DASD volume is compatible with IEHDASDR.

Have a look at the first few records in the second file to give you an idea of the VOLSER of the dumped DASD volume. This will help you create the correct control statements for IEHDASDR to restore the volume.

Regards

Tom
 

?//DSKDSNR? JOB?? (ACCT#),
?//???????? 'PGMRNAME',???????????????????????????????????????? /*OPER*/
?//???????? CLASS=A,?????????????????????????????????????????? /*JCLAS*/
?//???????? MSGLEVEL=(1,1),
?//???????? MSGCLASS=X,
?//???????? NOTIFY=,
?//???????? TIME=30,
?//???????? USER=,GROUP=,PASSWORD=????????????????????????????? /*RACF*/
?//*?????????????????????????????????????????????????????????? /*JCTRL*/
?//*
?//*
?//* LIB: IPO1.JCLLIB(DSKDSNR)
?//* GDE: CBIPO MVS CUSTOMIZATION
?//* DOC: THIS JOB WILL USE DFDSS TO RESTORE SELECTED DATA SETS
?//*????? FROM BACKUP TAPES TO DASD.? THIS JOB ALSO ILLUSTRATES
?//*????? THE POWERFUL COMMAND LANGUAGE OF DFDSS.
?//*
?//* NOTE: THIS JOB IS PROVIDED AS AN EXAMPLE. IT USES THE M42CAT
?//*?????? VOLUME AND A TAPE VOLID OF TAPE01. THIS JOB SHOULD BE
?//*?????? MODIFIED FOR YOUR OWN ENVIRONMENT.
?//*
?//*????? RESTOR1 - THIS STEP WILL RESTORE FROM TAPE TO VOLUME "M42CAT? "
?//*????????????? ALL DATA SETS THAT MEET THE FOLLOWING CRITERIA:
?//*
?//*????????????? A) DATA SETS MUST BEGIN WITH "IPO1."
?//*????????????? B) EXCLUDING THOSE ENDING WITH "DOCLIB"
?//*????????????? C) DATA SETS MUST HAVE THE "DSCHA" BIT ON IN DSCB
?//*????????????? D) DATA SETS MUST HAVE BEEN CREATED AFTER 1/1/86
?//*????????????? E) DATA SETS MUST HAVE AN EXPIRATION DATE EQUAL
?//*???????????????? TO OR LESS THAN 12/31/99
?//*????????????? F) DATA SETS MUST HAVE BEEN REFERENCED AFTER
?//*???????????????? 3/3/86
?//*
?//*????????????? IF A DATA SET BEING RESTORED ALREADY EXISTS ON THE
?//*????????????? DASD VOLUME, THE RENAME PARAMETER IS USED IN PLACE
?//*????????????? OF THE FIRST QUALIFIER OF THE DATA SET NAME TO
//*????????????? ALLOCATE A NEW DATA SET AND THEN RESTORE IT.
//*
//*
//RESTOR1 EXEC PGM=ADRDSSU,REGION=3072K
//SYSPRINT DD? SYSOUT=*
//DASD1??? DD? DISP=OLD,UNIT=3380,VOL=SER=M42CAT
//BACKUP?? DD? DSN=BACKUP1.BY.DATASET,DISP=OLD,
//???????????? UNIT=3400-6,VOL=SER=TAPE01,
//???????????? LABEL=(1,SL)
//SYSIN??? DD? *
?????? RESTORE INDDNAME(BACKUP) -
?????????????? OUTDDNAME(DASD1) -
?????????? DATASET(INCLUDE(IPO1.**)?? /* RESTORE ALL IPO1 DSNS? */???? +
?????????????????? EXCLUDE(IPO1.DOCLIB)?????? /* EXCEPT IPO1.DOCLIB??? +
????????????????????? BY((DSCHA,EQ,1)????? /* THAT HAVE BEEN CHANGED */+
???????????????????????? (CREDT,GT,86001)? /* CREATED AFTER 1/1/86?? */+
???????????????????????? (EXPDT,LE,99365)? /* EXPIRE BY 12/31/99 AND */+
???????????????????????? (REFDT,GT,86062))) /*REFERENCED AFTER 3/3/86*/+
????????????? RENAME(M42CAT)???????????? /* RENAME DUPLICATES????? */
/*
//*



regards;

Rahim



??



On Tuesday, May 14, 2024 at 04:49:47 PM CDT, <mspitz@...> wrote:


I have a file, fairly old, that looks like it is a DASDI dump restore tape.? It is clearly an EBCIDIC tape.? I am not even sure what is on it as I probably received this in the late 1990's.?

I would like to restore it, if possible.? I'm guessing it is a dump of a 3330, but I don't know an do not know enough about the format of a DASDI dump/restore tape to figure it out.? Also I'm not sure what format it is in as the filetype says TAP.

So, how do I mount this on Hercules?? Just like any other tape (het or aws) or something else.

I'm presuming that once I get it mounted TAPEMAP will help me figure out what is on it and what DASD volume type I need to restore it.

If it is a DASDI dump tape, I guessing I can just IPL from it and restore it to DASD as I would have years ago, but that may not be a correct/best approach in this instance.

Guidance will be appreciated.

By the way here is a png of the first part of the file.

Thanks,
?- Mark

 

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW.? I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

?- Mark
 

Hi Mark,
Have you tried specifying the ARCHLVL in your config ?

ARCHLVL ? S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

  • use S/370 for OS/360, VM/370, and MVS 3.8.
  • use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
  • use z/Arch or ESAME for z/OS and zLinux. This is the default.


---
¦Ó¦Ò³¾

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW.? I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

?- Mark


--
--
¦Ó¦Ò³¾
 

¿ªÔÆÌåÓý

Some software require BCMode and Not ECmode..

?

From: [email protected] <[email protected]> On Behalf Of botongrui, aka tsm. via groups.io
Sent: Thursday, May 16, 2024 5:06 AM
To: [email protected]
Subject: Re: [H390-MVS] help with restoring a dasdi dump/restore tape

?

Hi Mark,

Have you tried specifying the ARCHLVL in your config ?

?

ARCHLVL ? S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

¡¤???????? use S/370 for OS/360, VM/370, and MVS 3.8.

¡¤???????? use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.

¡¤???????? use z/Arch or ESAME for z/OS and zLinux. This is the default.

?

?

---

¦Ó¦Ò³¾

?

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW.? I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

?- Mark

?


--
--
¦Ó¦Ò³¾

 

Hercules in ARCHMODE S/370, like all S/370 systems, starts in BC mode and switches to EC mode when the operating system loads a PSW with the EC mode bit on.


On Thu, May 16, 2024 at 5:03?PM Mike Ward via <antebios1153=[email protected]> wrote:

Some software require BCMode and Not ECmode..

?

From: [email protected] <[email protected]> On Behalf Of botongrui, aka tsm. via
Sent: Thursday, May 16, 2024 5:06 AM
To: [email protected]
Subject: Re: [H390-MVS] help with restoring a dasdi dump/restore tape

?

Hi Mark,

Have you tried specifying the ARCHLVL in your config ?

?

ARCHLVL ? S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

¡¤???????? use S/370 for OS/360, VM/370, and MVS 3.8.

¡¤???????? use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.

¡¤???????? use z/Arch or ESAME for z/OS and zLinux. This is the default.

?

?

---

¦Ó¦Ò³¾

?

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW.? I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

?- Mark

?


--
--
¦Ó¦Ò³¾



--
Jay Maynard
 

¿ªÔÆÌåÓý

What follows is me looking into the mists beyond my actual competence.? However I think you'll need to go back to however this 'tape' file was created.? It does not look like an AWS format, nor any tape file format that I know of.
At offset x'c0' I see:
- a read CCW (x'02') of 80 bytes into address x'7c00'
- a TIC CCW (x'08') to x'7c00'
which appears to be a standard IPL process.? This would read the next block into x'7c00', the data would be one, or more, read CCWs to read subsequent blocks off the tape and then transfer to continue processing those CCWs to actually read the remaining data. And we can see these from offset x'5c' onwards reading 80 byte records at locations increasing by 72 bytes (presumably to overwrite the sequence number on the previous 80 byte record).
So what is the rest of the data?? If this was an AWS formatted tape, then the initial x'5000', x'0000' would mean there was an 80 byte record? following and there were no preceeding records, however it would be followed by a two byte flag field - presumably x'a000'- this chunk is an entire record and is not the end-of-file.? In this case it is not - it is followed by what looks like a sense CCW.
All-in-all it appears to me to be a set of 80 byte card images copied into a V-type format file, with the record lengths converted from big- to little-endian and ignoring the length of the 'RDW'.? I have no idea why the subsequent x'5000 0000' lengths come in pairs.? Possibly it was originally written to tape as LABEL=(,NL),RECFM=F,LRECL=80 .
Possibly the only way of IPLing off it would be to reformat into 80 byte records without the x'5000 0000' full-words - either in AWS format (where they come back as part of the AWS header) or simply a series of 80 byte records jammed together which could be IPLed off a card reader - which expects 80 byte records.?? Because the CCWs are 8 bytes in length they are in S/370 (not z/Arch) format so you would need to, as suggested, IPL in S/370 or ESA/390 mode.
TAPEMAP will be of no help - at best it is an unlabelled tape so there are no tape header (or trailer) records.
James Campbell
On 16 May 2024 at 10:05, botongrui, aka ¦Ó¦Ò³¾. via groups.io wrote:
> Hi Mark,
> Have you tried specifying the ARCHLVL in your config ?
>
> ARCHLVL S/370 | ESA/390 | ESAME | z/Arch
>
> Specifies the initial architecture mode:
>
> - use S/370 for OS/360, VM/370, and MVS 3.8.
> - use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
> - use z/Arch or ESAME for z/OS and zLinux. This is the default.
>
> ---
> ¦Ó¦Ò³¾
>
> On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:
>
> > Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW. I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.
> >
> > Anyway thanks for all the help.
> >
> > - Mark
> >
>

 

Where did you get the tape and how was it created? That may be a .TAP format tape...which is the format?used by SIMH, but not Hercules.

Grab a copy of vtapeutils, rename the file to end in .tap, then try converting to AWSTAPE.



On Thu, May 16, 2024 at 7:37?PM jacampbellaus via <jacampbellaus=[email protected]> wrote:
What follows is me looking into the mists beyond my actual competence.? However I think you'll need to go back to however this 'tape' file was created.? It does not look like an AWS format, nor any tape file format that I know of.
At offset x'c0' I see:
- a read CCW (x'02') of 80 bytes into address x'7c00'
- a TIC CCW (x'08') to x'7c00'
which appears to be a standard IPL process.? This would read the next block into x'7c00', the data would be one, or more, read CCWs to read subsequent blocks off the tape and then transfer to continue processing those CCWs to actually read the remaining data. And we can see these from offset x'5c' onwards reading 80 byte records at locations increasing by 72 bytes (presumably to overwrite the sequence number on the previous 80 byte record).
So what is the rest of the data?? If this was an AWS formatted tape, then the initial x'5000', x'0000' would mean there was an 80 byte record? following and there were no preceeding records, however it would be followed by a two byte flag field - presumably x'a000'- this chunk is an entire record and is not the end-of-file.? In this case it is not - it is followed by what looks like a sense CCW.
All-in-all it appears to me to be a set of 80 byte card images copied into a V-type format file, with the record lengths converted from big- to little-endian and ignoring the length of the 'RDW'.? I have no idea why the subsequent x'5000 0000' lengths come in pairs.? Possibly it was originally written to tape as LABEL=(,NL),RECFM=F,LRECL=80 .
Possibly the only way of IPLing off it would be to reformat into 80 byte records without the x'5000 0000' full-words - either in AWS format (where they come back as part of the AWS header) or simply a series of 80 byte records jammed together which could be IPLed off a card reader - which expects 80 byte records.?? Because the CCWs are 8 bytes in length they are in S/370 (not z/Arch) format so you would need to, as suggested, IPL in S/370 or ESA/390 mode.
TAPEMAP will be of no help - at best it is an unlabelled tape so there are no tape header (or trailer) records.
James Campbell
On 16 May 2024 at 10:05, botongrui, aka ¦Ó¦Ò³¾. via wrote:
> Hi Mark,
> Have you tried specifying the ARCHLVL in your config ?
>
> ARCHLVL S/370 | ESA/390 | ESAME | z/Arch
>
> Specifies the initial architecture mode:
>
> - use S/370 for OS/360, VM/370, and MVS 3.8.
> - use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
> - use z/Arch or ESAME for z/OS and zLinux. This is the default.
>
> ---
> ¦Ó¦Ò³¾
>
> On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:
>
> > Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW. I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.
> >
> > Anyway thanks for all the help.
> >
> > - Mark
> >
>



--
Jay Maynard
 

Thank you Jay.

I do not know how it was created, but I spent most of today looking at it and it is not an AWS tape or anything else I could find.

The person I got it from has passed away, so I cannot ask them. You are most likely correct and I will try vtapeutils next week.

Actually this exercise has been fun for me.? I left the MVS world in the early '90s and other than working on a few low level device interfaces to IBM mainframe devices from Windows I have not touched any IBM mainframe in decades.

So, after 20+ years I'm returning, at some level, to my roots.

I will update after I try vtapeutils.

Have a good weekend,
?- Mark Spitz
 

Sounds like an object program punched onto a card image.

On Thu, May 16, 2024 at 7:37?PM jacampbellaus via groups.io
<jacampbellaus@...> wrote:

What follows is me looking into the mists beyond my actual competence. However I think you'll need to go back to however this 'tape' file was created. It does not look like an AWS format, nor any tape file format that I know of.
At offset x'c0' I see:
- a read CCW (x'02') of 80 bytes into address x'7c00'
- a TIC CCW (x'08') to x'7c00'
which appears to be a standard IPL process. This would read the next block into x'7c00', the data would be one, or more, read CCWs to read subsequent blocks off the tape and then transfer to continue processing those CCWs to actually read the remaining data. And we can see these from offset x'5c' onwards reading 80 byte records at locations increasing by 72 bytes (presumably to overwrite the sequence number on the previous 80 byte record).
So what is the rest of the data? If this was an AWS formatted tape, then the initial x'5000', x'0000' would mean there was an 80 byte record following and there were no preceeding records, however it would be followed by a two byte flag field - presumably x'a000'- this chunk is an entire record and is not the end-of-file. In this case it is not - it is followed by what looks like a sense CCW.
All-in-all it appears to me to be a set of 80 byte card images copied into a V-type format file, with the record lengths converted from big- to little-endian and ignoring the length of the 'RDW'. I have no idea why the subsequent x'5000 0000' lengths come in pairs. Possibly it was originally written to tape as LABEL=(,NL),RECFM=F,LRECL=80 .
Possibly the only way of IPLing off it would be to reformat into 80 byte records without the x'5000 0000' full-words - either in AWS format (where they come back as part of the AWS header) or simply a series of 80 byte records jammed together which could be IPLed off a card reader - which expects 80 byte records. Because the CCWs are 8 bytes in length they are in S/370 (not z/Arch) format so you would need to, as suggested, IPL in S/370 or ESA/390 mode.
TAPEMAP will be of no help - at best it is an unlabelled tape so there are no tape header (or trailer) records.
James Campbell
On 16 May 2024 at 10:05, botongrui, aka ¦Ó¦Ò³¾. via groups.io wrote:
Hi Mark,
Have you tried specifying the ARCHLVL in your config ?

ARCHLVL S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

- use S/370 for OS/360, VM/370, and MVS 3.8.
- use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
- use z/Arch or ESAME for z/OS and zLinux. This is the default.

---
¦Ó¦Ò³¾

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW. I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

- Mark


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
 

Here's a historical description of the process of using punched object
program decks before transitioning to dasd storage.


On Fri, May 17, 2024 at 6:48?AM Mike Schwab via groups.io
<Mike.A.Schwab@...> wrote:

Sounds like an object program punched onto a card image.

On Thu, May 16, 2024 at 7:37?PM jacampbellaus via groups.io
<jacampbellaus@...> wrote:

What follows is me looking into the mists beyond my actual competence. However I think you'll need to go back to however this 'tape' file was created. It does not look like an AWS format, nor any tape file format that I know of.
At offset x'c0' I see:
- a read CCW (x'02') of 80 bytes into address x'7c00'
- a TIC CCW (x'08') to x'7c00'
which appears to be a standard IPL process. This would read the next block into x'7c00', the data would be one, or more, read CCWs to read subsequent blocks off the tape and then transfer to continue processing those CCWs to actually read the remaining data. And we can see these from offset x'5c' onwards reading 80 byte records at locations increasing by 72 bytes (presumably to overwrite the sequence number on the previous 80 byte record).
So what is the rest of the data? If this was an AWS formatted tape, then the initial x'5000', x'0000' would mean there was an 80 byte record following and there were no preceeding records, however it would be followed by a two byte flag field - presumably x'a000'- this chunk is an entire record and is not the end-of-file. In this case it is not - it is followed by what looks like a sense CCW.
All-in-all it appears to me to be a set of 80 byte card images copied into a V-type format file, with the record lengths converted from big- to little-endian and ignoring the length of the 'RDW'. I have no idea why the subsequent x'5000 0000' lengths come in pairs. Possibly it was originally written to tape as LABEL=(,NL),RECFM=F,LRECL=80 .
Possibly the only way of IPLing off it would be to reformat into 80 byte records without the x'5000 0000' full-words - either in AWS format (where they come back as part of the AWS header) or simply a series of 80 byte records jammed together which could be IPLed off a card reader - which expects 80 byte records. Because the CCWs are 8 bytes in length they are in S/370 (not z/Arch) format so you would need to, as suggested, IPL in S/370 or ESA/390 mode.
TAPEMAP will be of no help - at best it is an unlabelled tape so there are no tape header (or trailer) records.
James Campbell
On 16 May 2024 at 10:05, botongrui, aka ¦Ó¦Ò³¾. via groups.io wrote:
Hi Mark,
Have you tried specifying the ARCHLVL in your config ?

ARCHLVL S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

- use S/370 for OS/360, VM/370, and MVS 3.8.
- use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
- use z/Arch or ESAME for z/OS and zLinux. This is the default.

---
¦Ó¦Ò³¾

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW. I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

- Mark


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?





--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
 

If you can get this uploaded binary into a PS file and remove the IPL
code, you should have the object deck from the compiler, and be able
to run with PGM=LOADER or PGM=LINK to create a load module in a load
module library. It will depend on the compiler run time libraries
being available so if you see a program product number or the program
names in the start of the object deck we can tell you what libraries
to include.

On Fri, May 17, 2024 at 6:48?AM Mike Schwab <mike.a.schwab@...> wrote:

Sounds like an object program punched onto a card image.

On Thu, May 16, 2024 at 7:37?PM jacampbellaus via groups.io
<jacampbellaus@...> wrote:

What follows is me looking into the mists beyond my actual competence. However I think you'll need to go back to however this 'tape' file was created. It does not look like an AWS format, nor any tape file format that I know of.
At offset x'c0' I see:
- a read CCW (x'02') of 80 bytes into address x'7c00'
- a TIC CCW (x'08') to x'7c00'
which appears to be a standard IPL process. This would read the next block into x'7c00', the data would be one, or more, read CCWs to read subsequent blocks off the tape and then transfer to continue processing those CCWs to actually read the remaining data. And we can see these from offset x'5c' onwards reading 80 byte records at locations increasing by 72 bytes (presumably to overwrite the sequence number on the previous 80 byte record).
So what is the rest of the data? If this was an AWS formatted tape, then the initial x'5000', x'0000' would mean there was an 80 byte record following and there were no preceeding records, however it would be followed by a two byte flag field - presumably x'a000'- this chunk is an entire record and is not the end-of-file. In this case it is not - it is followed by what looks like a sense CCW.
All-in-all it appears to me to be a set of 80 byte card images copied into a V-type format file, with the record lengths converted from big- to little-endian and ignoring the length of the 'RDW'. I have no idea why the subsequent x'5000 0000' lengths come in pairs. Possibly it was originally written to tape as LABEL=(,NL),RECFM=F,LRECL=80 .
Possibly the only way of IPLing off it would be to reformat into 80 byte records without the x'5000 0000' full-words - either in AWS format (where they come back as part of the AWS header) or simply a series of 80 byte records jammed together which could be IPLed off a card reader - which expects 80 byte records. Because the CCWs are 8 bytes in length they are in S/370 (not z/Arch) format so you would need to, as suggested, IPL in S/370 or ESA/390 mode.
TAPEMAP will be of no help - at best it is an unlabelled tape so there are no tape header (or trailer) records.
James Campbell
On 16 May 2024 at 10:05, botongrui, aka ¦Ó¦Ò³¾. via groups.io wrote:
Hi Mark,
Have you tried specifying the ARCHLVL in your config ?

ARCHLVL S/370 | ESA/390 | ESAME | z/Arch

Specifies the initial architecture mode:

- use S/370 for OS/360, VM/370, and MVS 3.8.
- use ESA/390 for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA, Linux/390, and ZZSA.
- use z/Arch or ESAME for z/OS and zLinux. This is the default.

---
¦Ó¦Ò³¾

On Thursday, 16 May 2024 at 05:31, mspitz@... <mspitz@...> wrote:

Thanks for all of the help. Hercules will not IPL the tape, it says it is a s/360 PSW. I'm sure that is correct, and if so, I will try to figure out skip the IPL portion of the tape and then see what I can do.

Anyway thanks for all the help.

- Mark


--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
 

If the assumption is that the tape uses something like the 'two card loader' to load object deck into storage
for execution, I do not expect that suggestion to work. The deck contains code which is meant to run 'stand alone',
it does not use any facilities from an operating system and so on. And will certainly execute instruktions which
require supervisor state and thus program check when run as a regular program. And most likely it is written
to be running in 'fixed locations'.
andersedlund@...
 

Hi all,

Got it figured out.? It is an OS360 distribution tape,

Thanks to Jay for recognizing that is was a .TAP tape and pointing me to vtapeutils to convert it to an aws tape.

I'm not sure of the release as I did most of the diagnostics by hand. I was able to get hercules to IPL it but had some trouble finding a reference manual with information on the control cards for the restore.

Anyway, I can't spend any more time on it right now, but at least I now know what is on the tape.

Thanks again,

?- Mark Spitz

1 - 19 of 19