Re: questions about STXIT and EXIT in DOS/VS, DOS/VSE, VSE/SP, etc.
Thank you, sir ...
That should help me to get started with this little project ...
All the best,
Mark S. Waterbury
|
Re: questions about STXIT and EXIT in DOS/VS, DOS/VSE, VSE/SP, etc.
Mark Waterbury wrote: Does anyone have some example(s) of using STXIT to trap
e.g. illegal opcodes or unimplemented SVCs, e.g. to handle them
in some way, such as by emulating the missing functionality,
before using EXIT to resume program execution? The manual explains how to use both STXIT and EXIT: * GC33-5373-02 DOS-VS Supervisor and I-O Macros See pages 276 (STXIT) and 280 (EXIT). As far as a usage example goes, while it may not necessarily be a very good example, my MODESETT program (which is just a simple test of my MODESET macro) uses both STXIT and EXIT, so you may (or may not!) find it useful. It's in my "#fish-macros.zip" file in the group's Files area: * /g/H390-DOSVS/files * /g/H390-DOSVS/files/%23fish-macros.zipHope that helps! -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
questions about STXIT and EXIT in DOS/VS, DOS/VSE, VSE/SP, etc.
Hello, all,
Happy 2023 to everyone.
Does anyone have some example(s) of using STXIT to trap e.g. illegal opcodes or unimplemented SVCs, e.g. to handle them in some way, such as by emulating the missing functionality, before using EXIT to resume program execution?
Thanks in advance.
All the best,
Mark S. Waterbury
|
On Wed, Oct 19, 2022 at 05:55 PM, Jim Snellen wrote:
YROFFSET worked like a charm.
Well, it will eliminate the date? problem on a DOS/VS guest, but I discovered that it has a side effect on KICKS, which will then not start because of it. Just wanted to let you know. :-) Cheers, Rene FERLAND, Montreal
|
Re: DOS/VS Handshaking as VM/CE Guest
I got a real thrill out of looking at those code examples.
Took me right back to my 1970s systems programmer days.......
Steve
Fish wrote:
> Jim Snellen wrote:
> > Fish wrote:
> >
> > > Wouldn't it be better to just directly fix the supervisor
> > > generation macro instead? (to support a new e.g. VM=YES|NO
> > > option?)
> > >
> > > Then no zap would be involved at all. You could generate a
> > > new supervisor at any time and would be guaranteed of always
> > > having VM handshaking support as long as VM=YES was specified.
> > > <shrug>
> > >
> > > Or is doing that somehow undesirable?
> > >
> > > <me: slightly confused>
> >
> > Fish,
> > That certainly would be a great way of addressing this issue.
> > Given this was your idea, I¡¯ll let you choose the supervisor
> > macro to modify and write the code to do it.? I certainly don¡¯t
> > have expertise to do it.
> >
> > Best regards,
> > Jim
>
> Well, I'm kind of busy with something else right now, but what the
> hell. It should be fairly easy.
Here's a copy of the email I just sent to Ren¨¦ just now, with a copy of the attachment inlined further below:
While I have NOT tested it, I believe the attached should do the trick.
It's still unclear to me however, WHY that particular bit needs to be set in order for things to work right. I'm going to GUESS that maybe some JOBCTL phase (or perhaps a POWER/VS phase?) is checking that particular bit to determine whether VM handshaking support exists or not? (and if it does, it then issues SVC 56?)
But that's just a guess. :)
(It's been TOO many years since I've messed with DOS/VS(E) and VM!)
? ? * $$ JOB JNM=FOPT,CLASS=0
? ? * $$ PUN DISP=I,CLASS=0
? ? * $$ LST CLASS=A,JSEP=0
? ? // JOB FOPT ESERV UPDATE E.FOPT
? ? // EXEC PGM=ASSEMBLY
? ? ? ? ? ? ?PUNCH '// JOB ASMSVC FOPT'
? ? ? ? ? ? ?PUNCH '// OPTION EDECK '
? ? ? ? ? ? ?PUNCH '// EXEC ASSEMBLY '
? ? ? ? ? ? ?END
? ? /*
? ? // EXEC ESERV
? ? ?GENEND
? ? ?DSPCH E.FOPT
? ? ) COL 73,8
? ? ) VER 22560034,46
? ? SYSFLAG4 DC? ? B'0&BGDAT2&BGVSAM.0&BLXECB.000'
? ? ) REP 22560034
? ? SYSFLAG4 DC? ? B'0&BGDAT2&BGVSAM.0&BLXECB.001'
? ? ) END
? ? /*
? ? // EXEC ASSEMBLY
? ? ? ? ? ? ?PUNCH '/* '
? ? ? ? ? ? ?PUNCH '/&& '
? ? ? ? ? ? ?END
? ? /*
? ? /&
? ? * $$ EOJ
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: dosvs rel 34 3270 program in asm
Thank you.? It has what I was looking for and a "BUNCH" of extra.
Study Hall time.................
Cheers /tomc
Tom Chandler wrote:
> I am looking for an example of a 3270 program written in DOSVS
> rel 34 ASM.
>
> Want to try and learn some things.? If anyone has an example
> or location of example, please advise.
Hi Tom!
I don't recall where I found the attached files, but hopefully you will find them useful?
It looks like there're only two 3270 samples, both in the "Access Methods" directory. One called "demo3270" and the other called "demobtam". (See attached readme)
I have NOT tried either, so I don't know whether they work or not, nor even whether they're useful to you.
But hey, I tried! :)
Hope that helps!
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: dosvs rel 34 3270 program in asm
Hi Fish,
Thanks so much for sharing these programs, I have found them extremely useful, especially the examples with channel appendage and the various exits.
Best regards,
Steen
|
Re: dosvs rel 34 3270 program in asm
Tom Chandler wrote: I am looking for an example of a 3270 program written in DOSVS
rel 34 ASM.
Want to try and learn some things. If anyone has an example
or location of example, please advise. Hi Tom! I don't recall where I found the attached files, but hopefully you will find them useful? It looks like there're only two 3270 samples, both in the "Access Methods" directory. One called "demo3270" and the other called "demobtam". (See attached readme) I have NOT tried either, so I don't know whether they work or not, nor even whether they're useful to you. But hey, I tried! :) Hope that helps! -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
POWER/VS "DISP=I" (insert) JECL
FYI: I can't recall whether I've ever mentioned this before or not, but in case I haven't, I just wanted to pass along a handy helpful tip to those DOS/VS(E) geeks out there who might not already know about POWER/VS's little know (but incredibly handy!) "DISP=I" JECL command: POWER/VS "DISP=I" (insert) Example job stream to catalog the "A." source for a macro, and then also automatically catalog the "edited" E deck too via the little know but incredibly handy POWER/VS "DISP=I" JECL command (DISP=I means "insert", as in "automatically insert the specified spooled device output back into the card reader"). Note the "DISP=I" usage on the "* $$ PUN" punch card midway through the below job stream where punched output is normally spooled: * $$ JOB JNM=BAS,CLASS=0 * $$ LST CLASS=A // JOB BAS CATALS A.BAS // ASSGN SYS001,SYSRES // ASSGN SYS002,SYSRES // EXEC MAINT CATALS A.BAS BKEND MACRO &BAS BAS &R14,&SUBRTN &BAS DC 0H'0',X'4D',AL.4(&R14,0),S(&SUBRTN) MEND BKEND /* /& * $$ PUN CLASS=A,DISP=I
// JOB BAS EDECK ASSEMBLY A.BAS TO E.BAS // ASSGN SYSLST,IGN // OPTION DECK // EXEC ASSEMBLY PUNCH '* $$ JOB JNM=BAS,CLASS=0,DISP=D' PUNCH '* $$ LST CLASS=A,DISP=D' PUNCH '// JOB BAS CATALS E.BAS EDITED MACRO' PUNCH '// EXEC MAINT' END /* // RESET SYSLST // OPTION EDECK,NODECK // EXEC ASSEMBLY COPY BAS END /* // ASSGN SYSLST,IGN // OPTION DECK // EXEC ASSEMBLY PUNCH '/*' PUNCH '/&&' PUNCH '* $$ EOJ' END /* /& * $$ EOJ The end result is, the macro is automatically cataloged to BOTH the A. and E. source sublibraries with one simple submission of a simple job stream. There is NO NEED to manually capture the punched output from // OPTION EDECK assembly and then manually wrap it with JCL and manually submit it to catalog the "edited" macro to the E. sublibrary. Instead, by simply using a "DISP=I" JECL card, it is done for you automatically in one job stream! -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: DOS/VS Handshaking as VM/CE Guest
Fish wrote: Jim Snellen wrote:
Fish wrote:
Wouldn't it be better to just directly fix the supervisor
generation macro instead? (to support a new e.g. VM=YES|NO
option?)
Then no zap would be involved at all. You could generate a
new supervisor at any time and would be guaranteed of always
having VM handshaking support as long as VM=YES was specified.
<shrug>
Or is doing that somehow undesirable?
<me: slightly confused> Fish,
That certainly would be a great way of addressing this issue.
Given this was your idea, I¡¯ll let you choose the supervisor
macro to modify and write the code to do it. I certainly don¡¯t
have expertise to do it.
Best regards,
Jim Well, I'm kind of busy with something else right now, but what the
hell. It should be fairly easy. Here's a copy of the email I just sent to Ren¨¦ just now, with a copy of the attachment inlined further below: While I have NOT tested it, I believe the attached should do the trick. It's still unclear to me however, WHY that particular bit needs to be set in order for things to work right. I'm going to GUESS that maybe some JOBCTL phase (or perhaps a POWER/VS phase?) is checking that particular bit to determine whether VM handshaking support exists or not? (and if it does, it then issues SVC 56?) But that's just a guess. :) (It's been TOO many years since I've messed with DOS/VS(E) and VM!) * $$ JOB JNM=FOPT,CLASS=0 * $$ PUN DISP=I,CLASS=0 * $$ LST CLASS=A,JSEP=0 // JOB FOPT ESERV UPDATE E.FOPT // EXEC PGM=ASSEMBLY PUNCH '// JOB ASMSVC FOPT' PUNCH '// OPTION EDECK ' PUNCH '// EXEC ASSEMBLY ' END /* // EXEC ESERV GENEND DSPCH E.FOPT ) COL 73,8 ) VER 22560034,46 SYSFLAG4 DC B'0&BGDAT2&BGVSAM.0&BLXECB.000' ) REP 22560034 SYSFLAG4 DC B'0&BGDAT2&BGVSAM.0&BLXECB.001' ) END /* // EXEC ASSEMBLY PUNCH '/* ' PUNCH '/&& ' END /* /& * $$ EOJ -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: DOS/VS Handshaking as VM/CE Guest
Jim Snellen wrote: Fish,
I¡¯ll be glad to send it to you. If you have VM/370 CE, log on
to DOSVS. The DOSVS mini disk 191 A contains the two files you
asked for as well as the original supervisor and zap jobs. Ren¨¦ already sent them to me. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
dosvs rel 34 3270 program in asm
I am looking for an example of a 3270 program written in DOSVS rel 34 ASM.
Want to try and learn some things.? If anyone has an example or location of
example, please advise.
Thank You
tom c
|
Re: DOS/VS Handshaking as VM/CE Guest
Fish,
I¡¯ll be glad to send it to you. If you have VM/370 CE, log on to DOSVS. The DOSVS mini disk 191 A contains the two files you asked for as well as the original supervisor and zap jobs.
Best regards,
Jim
toggle quoted message
Show quoted text
On Oct 25, 2022, at 11:33 AM, Fish Fish <david.b.trout@...> wrote:
?Jim Snellen wrote:
Fish wrote:
Wouldn't it be better to just directly fix the supervisor
generation macro instead? (to support a new e.g. VM=YES|NO
option?)
Then no zap would be involved at all. You could generate a
new supervisor at any time and would be guaranteed of always
having VM handshaking support as long as VM=YES was specified.
<shrug>
Or is doing that somehow undesirable?
<me: slightly confused> Fish,
That certainly would be a great way of addressing this issue.
Given this was your idea, I¡¯ll let you choose the supervisor
macro to modify and write the code to do it. I certainly don¡¯t
have expertise to do it.
Best regards,
Jim Well, I'm kind of busy with something else right now, but what the hell. It should be fairly easy.
To help speed things up, would you (or someone) please either upload, post the contents of, or send directly to me (preferred) the contents of the two mentioned files please? ("SGSVC UPDATE A", and "SGATAB UPDATE A").
Thanks.
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: DOS/VS Handshaking as VM/CE Guest
Jim Snellen wrote: Fish wrote:
Wouldn't it be better to just directly fix the supervisor
generation macro instead? (to support a new e.g. VM=YES|NO
option?)
Then no zap would be involved at all. You could generate a
new supervisor at any time and would be guaranteed of always
having VM handshaking support as long as VM=YES was specified.
<shrug>
Or is doing that somehow undesirable?
<me: slightly confused> Fish,
That certainly would be a great way of addressing this issue.
Given this was your idea, I¡¯ll let you choose the supervisor
macro to modify and write the code to do it. I certainly don¡¯t
have expertise to do it.
Best regards,
Jim Well, I'm kind of busy with something else right now, but what the hell. It should be fairly easy. To help speed things up, would you (or someone) please either upload, post the contents of, or send directly to me (preferred) the contents of the two mentioned files please? ("SGSVC UPDATE A", and "SGATAB UPDATE A"). Thanks. -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: DOS/VS Handshaking as VM/CE Guest
Fish,
That certainly would be a great way of addressing this issue. Given this was your idea, I¡¯ll let you choose the supervisor macro to modify and write the code to do it. I certainly don¡¯t have expertise to do it.
Best regards,
Jim
toggle quoted message
Show quoted text
On Oct 24, 2022, at 10:52 PM, Fish Fish <david.b.trout@...> wrote:
?Wouldn't it be better to just directly fix the supervisor generation macro instead? (to support a new e.g. VM=YES|NO option?)
Then no zap would be involved at all. You could generate a new supervisor at any time and would be guaranteed of always having VM handshaking support as long as VM=YES was specified. <shrug>
Or is doing that somehow undesirable?
<me: slightly confused>
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Snellen
Sent: Monday, October 24, 2022 7:01 PM
To: [email protected]
Subject: [H390-DOSVS] DOS/VS Handshaking as VM/CE Guest
Importance: High
If anyone chooses to re-assemble the DOS/VS supervisor, I will first
recommend creating a new one, defining a new name (ie. $$A$SUPx). After
doing so, the POWER statement to spool output to VM (PSTART LST,00E,A,,VM)
will not work. A PDZAP is required. Following is a dialog between me and
Professor Rene Ferland which corrects this situation.
--------------------------------------------------------------------
Greetings Professor Ferland,
I apologize for contacting you directly and, if you prefer, I'll open a
thread on /g/H390-DOSVS </g/H390-DOSVS>
.
On 8/14/21, in response to Steve Orso, you wrote:
On Fri, Aug 13, 2021 at 03:20 PM, <stephen.orso@...> wrote:
[...] and in particular what you need to do to run it under VM/370.
Have you run your DOS/360 under VM/370? It should not be very hard. But
the one problem I see is handshaking (automatic close of spool print/punch
files), probably not implemented on DOS/360. The OS has to be patched for
that. George Shedlock did it for DOS/VS.
Cheers,
Rene FERLAND, Montreal
I'm particularly interested in the bold statements in your response.
I generated a supervisor to change the storage allocations for each
partition. After re-IPLing with the new supervisor, I've lost the ability
to spool print to VM/CE using HercPRT. Is there a subsequent task to be
done?
--
Best Regards,
Jim Snellen
FIRST RESPONSE
Hello Jim,
Unfortunately, I am not sure I can help you. George Shedlock is the one
who implemented handshaking. He knew the operating system, assembler and
what to do. Me I can only guess from the jobs he provided.
If you logon to the DOSVS virtual machine, minidisk 191 contains all the
material of George Shedlock. There are two update jobs: SGSVC UPDATE A,
and SGATAB UPDATE A. From what I understand, the first is to update (or
add?) supervisor call SVC56 (presumably for handshaking). It will punch a
job in the reader queue that has then to be run to perform the update. The
same is true for SGATAB UPDATE A, which updates the tables and constants.
If you just changed the supervisor, I would assume you don't have to run
these jobs again. The updates they made are likely still there.
What you probably need to do is change/run the job $$A$SUP1 ZAPS A. This
job modifies the $$A$SUP1 phase in the core library for handshaking. It
makes a very small change to the supervisor binary at a specific address.
Presumably, when you re-assembled the supervisor, your new binary does not
have the modification and that's why handshaking does not work anymore. I
don't know if you can run George Shedlock's job as such for your new
supervisor, or if you need to change the address because of the changes
you made. One possible way to find out is to re-assemble George Shedlock
original supervisor ($$A$SUP1 DOSVS A) and examine the listing to
determine where the ZAP is done and find the equivalent in your new
supervisor.
That's the best I can do for you.
Good luck!
Rene FERLAND, Montreal
SECOND RESPONSE
Hello Jim,
I have assembled George Shedlock's original $$A$SUP1 supervisor and I can
see what the ZAP has done to it.
It (apparently) changes the last bit of SYSFLAG4 (check the PNG attached):
I think the ZAP says to check (VER) for 6001,6808 at address 738 and, if
it is there, replace it with 6001,6809 (REP).
So, check your own supervisor for SYSFLAG4, find the address and value,
and adjust the ZAP accordingly? :-)
Cheers,
Rene FERLAND, Montreal
REPLY
Hello Professor,
As always, you have come through again! My changes to the new supervisor
did not change the offset so I was able to run the PDZAP using the new
name. The VM handshake works wonderfully.
With your permission, I will post this dialog on /g/H390-
DOSVS </g/H390-DOSVS> so that others may benefit from
your wisdom.
Thank you.
Attachments area
|
Re: DOS/VS Handshaking as VM/CE Guest
Wouldn't it be better to just directly fix the supervisor generation macro instead? (to support a new e.g. VM=YES|NO option?)
Then no zap would be involved at all. You could generate a new supervisor at any time and would be guaranteed of always having VM handshaking support as long as VM=YES was specified. <shrug>
Or is doing that somehow undesirable?
<me: slightly confused>
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jim
Snellen
Sent: Monday, October 24, 2022 7:01 PM
To: [email protected]
Subject: [H390-DOSVS] DOS/VS Handshaking as VM/CE Guest
Importance: High
If anyone chooses to re-assemble the DOS/VS supervisor, I will first
recommend creating a new one, defining a new name (ie. $$A$SUPx). After
doing so, the POWER statement to spool output to VM (PSTART LST,00E,A,,VM)
will not work. A PDZAP is required. Following is a dialog between me and
Professor Rene Ferland which corrects this situation.
--------------------------------------------------------------------
Greetings Professor Ferland,
I apologize for contacting you directly and, if you prefer, I'll open a
thread on /g/H390-DOSVS </g/H390-DOSVS>
.
On 8/14/21, in response to Steve Orso, you wrote:
On Fri, Aug 13, 2021 at 03:20 PM, <stephen.orso@...> wrote:
[...] and in particular what you need to do to run it under VM/370.
Have you run your DOS/360 under VM/370? It should not be very hard. But
the one problem I see is handshaking (automatic close of spool print/punch
files), probably not implemented on DOS/360. The OS has to be patched for
that. George Shedlock did it for DOS/VS.
Cheers,
Rene FERLAND, Montreal
I'm particularly interested in the bold statements in your response.
I generated a supervisor to change the storage allocations for each
partition. After re-IPLing with the new supervisor, I've lost the ability
to spool print to VM/CE using HercPRT. Is there a subsequent task to be
done?
--
Best Regards,
Jim Snellen
FIRST RESPONSE
Hello Jim,
Unfortunately, I am not sure I can help you. George Shedlock is the one
who implemented handshaking. He knew the operating system, assembler and
what to do. Me I can only guess from the jobs he provided.
If you logon to the DOSVS virtual machine, minidisk 191 contains all the
material of George Shedlock. There are two update jobs: SGSVC UPDATE A,
and SGATAB UPDATE A. From what I understand, the first is to update (or
add?) supervisor call SVC56 (presumably for handshaking). It will punch a
job in the reader queue that has then to be run to perform the update. The
same is true for SGATAB UPDATE A, which updates the tables and constants.
If you just changed the supervisor, I would assume you don't have to run
these jobs again. The updates they made are likely still there.
What you probably need to do is change/run the job $$A$SUP1 ZAPS A. This
job modifies the $$A$SUP1 phase in the core library for handshaking. It
makes a very small change to the supervisor binary at a specific address.
Presumably, when you re-assembled the supervisor, your new binary does not
have the modification and that's why handshaking does not work anymore. I
don't know if you can run George Shedlock's job as such for your new
supervisor, or if you need to change the address because of the changes
you made. One possible way to find out is to re-assemble George Shedlock
original supervisor ($$A$SUP1 DOSVS A) and examine the listing to
determine where the ZAP is done and find the equivalent in your new
supervisor.
That's the best I can do for you.
Good luck!
Rene FERLAND, Montreal
SECOND RESPONSE
Hello Jim,
I have assembled George Shedlock's original $$A$SUP1 supervisor and I can
see what the ZAP has done to it.
It (apparently) changes the last bit of SYSFLAG4 (check the PNG attached):
I think the ZAP says to check (VER) for 6001,6808 at address 738 and, if
it is there, replace it with 6001,6809 (REP).
So, check your own supervisor for SYSFLAG4, find the address and value,
and adjust the ZAP accordingly? :-)
Cheers,
Rene FERLAND, Montreal
REPLY
Hello Professor,
As always, you have come through again! My changes to the new supervisor
did not change the offset so I was able to run the PDZAP using the new
name. The VM handshake works wonderfully.
With your permission, I will post this dialog on /g/H390-
DOSVS </g/H390-DOSVS> so that others may benefit from
your wisdom.
Thank you.
Attachments area
|
DOS/VS Handshaking as VM/CE Guest
If anyone chooses to re-assemble the DOS/VS supervisor, I will first recommend creating a new one, defining a new name (ie. $$A$SUPx).? After doing so, the POWER statement to spool output to VM (PSTART LST,00E,A,,VM) will not work.? A PDZAP is required.? Following is a dialog between me and Professor Rene Ferland which corrects this situation. --------------------------------------------------------------------
Greetings Professor Ferland,
?
I apologize for contacting you directly and, if you prefer, I'll open a thread on? /g/H390-DOSVS. ?
On 8/14/21, in response to Steve Orso, you wrote:
?
On Fri, Aug 13, 2021 at 03:20 PM, <stephen.orso@...> wrote:
[...] and in particular what you need to do to run it under VM/370.
Have you run your DOS/360 under VM/370? It should not be very hard. But the one problem I see is handshaking (automatic close of spool print/punch files), probably not implemented on DOS/360.?The OS has to be patched for that. George Shedlock did it for DOS/VS.
Cheers,
Rene FERLAND, Montreal
?
I'm particularly interested in the bold statements in your response.
?
I generated a supervisor to change the storage allocations for each partition.? After re-IPLing with the new supervisor, I've lost the ability to spool print to VM/CE using HercPRT.? Is there a subsequent task to be done?
--
Best Regards,
?
Jim Snellen FIRST RESPONSE
Hello Jim,Unfortunately, I am not sure I can help you. George Shedlock is the one who implemented handshaking. He knew the operating system, assembler and what to do. Me I can only guess from the jobs he provided.If you logon?to the DOSVS virtual machine, minidisk 191 contains all the material of George Shedlock. There are two update jobs: SGSVC UPDATE A, and SGATAB UPDATE A. From what I understand, the first is to update (or add?) supervisor call SVC56 (presumably for handshaking). It will punch a job in the reader queue that has then to be run to perform the update. The same is true for SGATAB UPDATE A, which updates the tables and constants. If you just changed the supervisor, I would assume you don't have to run these jobs again. The updates they made are likely still there.What you probably need to do is change/run the job $$A$SUP1 ZAPS A. This job modifies the $$A$SUP1 phase in the core library for handshaking. It makes a very small change to the supervisor binary at a specific address. Presumably, when you re-assembled the supervisor, your new binary does not have the modification and that's why handshaking does not work anymore. I don't know if you can run George Shedlock's job as such for your new supervisor, or if you need to change the address because of the changes you made. One possible way to find out is to re-assemble George Shedlock original supervisor ($$A$SUP1 DOSVS A) and examine the listing to determine where the ZAP is done and find the equivalent in your new supervisor.That's the best I can do for you.Good luck!Rene FERLAND, Montreal
SECOND RESPONSE
Hello Jim,
?
I have assembled George Shedlock's original $$A$SUP1 supervisor and I can see what the ZAP has done to it.
?
It (apparently) changes the last bit of SYSFLAG4 (check the PNG attached): I think the ZAP says to check (VER) for 6001,6808 at address 738 and, if it is there, replace it with 6001,6809 (REP).
?
So, check your own supervisor for SYSFLAG4, find the address and value, and adjust the ZAP accordingly? :-)
?
Cheers,
?
Rene FERLAND, Montreal
REPLY
Hello Professor,
As always, you have come through again!? My changes to the new supervisor did not change the offset so I was able to run the PDZAP using the new name.? The VM handshake works wonderfully.
?
With your permission, I will post this dialog on? /g/H390-DOSVS?so that others may benefit from your wisdom. ?
Thank you.
?
?
|
¸é±ð²Ô¨¦,
Thank you again for a splendid explanation!? YROFFSET worked like a charm.? I also refreshed the DOS disks to ensure they were George Shedlock's and the POWER printer task worked fine to VM using HercPRT.
This issue is closed.
Jim Snellen
|
Hello Jim,
Below some answers.
>> [...] my guest DOSVS machine has the correct time but is off one day in the future (plus 24 hours).
>> Where or how do I correct this?
?
This issue was raised in the past (in 2010). The best explanation comes from Bill Carlborg:
?
"DOS/VS is not "century aware" and the problem is in the date routines.? They calculate the number of years since 1900 since the TOD clock starts then.? It's fine until the year 2000 when that makes 100 years in the TOD clock.? If the date is in the form MMDDYY that one in the 100 will be in the day position.? DOS/VS adds a month field (MM0000) to a day? field (00DD00) to the year field (0000YY).? Except the year field is now more than 2 digits with a one in the position that belongs to the day.? So when it adds the three fields together to make MMDDYY the day is increased by one."
?
Bill proposed a "solution" if you don't want to start patching/updating system routines:
?
"What I did on my system was include a YROFFSET -100 in my Hercules config file.? This moves the TOD clock back a hundred years.? So the TOD clock might think it is 1922 but DOS/VS never uses the century part anyway so it doesn't even know or care.? And without the century it never could do any day of the week calculations so that is not an issue.? This seemed to be the easiest solution."
?
I tried it on VM/370 CE and it seems to work.
?
?
?
?
>> [...] but I get no output until I shutdown the DOSVS guest and logoff.
?
Because the DOS/VS system you use (see below) probably has not handshaking implemented.
?
?
?
?
>> Why am I getting this message (0P31D regarding 02C) ?
?
Because you are possibly using the DOS/VS system customized by Michel Beaulieu, instead of the original 5-pack of George Shedlock, to which the DOSVS directory entry of VM/370 CE applies. Here's a link to the "right" DOS/VS system:
?
http://dosvs.31bits.net/DOSVS_5Pack_V1.0-full.zip
?
If you use the DASDs in the ZIP above, you should not need to change the POWER job, and handshaking is implemented, so printing will work fine. It is certainly the case for me.
?
Cheers,
?
Rene FERLAND, Montreal
?
|
Hello guys, First, I want to thank my VM friends with the support they gave me on setting the time zone via DMKSYS.? VM runs great! I have several questions for DOS/VS Rel. 34 (George Shedlock files) running as a guest of VM/CE 1.1.2.
Now that VM has the correct day and time, my guest DOSVS machine has the correct time but is off one day in the future (plus 24 hours).? I tried the 'SET DATE=' command at IPL time and receive an INVALID RESPONSE message but the SET command with no parameters works fine.? For example, right now the date shows 10/19/22 when it is actually 10/18/22.? Where or how do I correct this?
I stopped the printer task via POWER via 'P 00E'.? I then restart it with 'S LST,00E,A,,VM' to indicate that output should be spooled to VM, but I get no output until I shutdown the DOSVS guest and logoff.? Shouldn't the above create a printer file in VM?? I am using HercPRT v1.8.0.5692 which should generate a PDF file.? Also, the printer device is defined as:
000E? ? 1403? ? 127.0.0.1:3213 sockdev cctape=(1=1,7=2,13=3,19=4,25=5,31=6,37=7,43=8,63=9,49=10,55=11,61=12)
BTW, VM files print just fine producing beautiful PDF files.
I keep getting the message
?
? ? ?F1 0P31D? R DVC NOT OP SYS015=02C? ? ? ? ? ?
? ? ? ? ? ?CCSW=? ?NOT AVAILABLE? ?CCB=A6A420? ?
? ? ? ? ? ?SNS=0? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
whenever I start POWER.? I respond with 'CANCEL' and all is well with POWER startup.? Why am I getting this message?? Finally, how do I edit the POWERV job executed in F1 (when 'ASSGN SYSIN,SYSRES' is entered)?? I want to see if/where/how the device 02C is being specified and also to start the LST task by spooling the output to VM.
|
Ren¨¦ Ferland
Jim Snellen
