[H390-MVS] LOGREC on any DASD device type - new USERMODs

[Greg Price [e-mail] [H390-MVS]]

Hi,

It seems Peppe's recent point about IFCDIP00 not handling all device
types has prompted Tom Armstrong to dig up some work he'd done to allow
LOGREC to reside on any DASD device type that the OS has general VTOC
and data set support for.

He sent them to me to package up, and so accordingly I can announce 3
new USERMODs which each update a module in order to provide generalized
and complete LOGREC DASD device type support.  There are 3 of them
because there are 3 different FMIDs involved.

The mods are:
ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC
I/O for EREP.

They can be downloaded from
http://www.prycroft6.com.au/vs2mods/index.html#zp60035

Cheers,
Greg

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Greg Price ***@optusnet.com.au [H390-MVS]
Hi,
It seems Peppe's recent point about IFCDIP00 not handling all device
types has prompted Tom Armstrong to dig up some work he'd done to allow
LOGREC to reside on any DASD device type that the OS has general VTOC
and data set support for.
He sent them to me to package up, and so accordingly I can announce 3
new USERMODs which each update a module in order to provide generalized
and complete LOGREC DASD device type support.  There are 3 of them
because there are 3 different FMIDs involved.
ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC
I/O for EREP.
They can be downloaded from
http://www.prycroft6.com.au/vs2mods/index.html#zp60035
Cheers,
Greg

Great! Thanks to you and Tom!

Not really ready to apply the mods, I'm still reading for
possibly implementing a personal "sysgen", modeled over
the Jay Moseley "SYSGEN", but to be executed from an already
running MVS3.8j, instead than from the original starter kit.

I started to keep a personal, "totally private", blog,
for keeping track of what I'm learning on this topic.

I'all add your comment for future references to my just
born blog.

I'm "forcing myself", for this plan, to use only the MVS
batch subsystem, from the hercules console or from the
linux shell command line.

I'm probably in the same "state" of people of the seventy
"punching cards" into an OS/VS1 system, isn't? ;-)

And I learned more in a week of "punching cards" than in months
at the TSO prompt ... ;-)

Thanks again, Peppe.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Greg Price ***@optusnet.com.au [H390-MVS]
Hi,
It seems Peppe's recent point about IFCDIP00 not handling all device
types has prompted Tom Armstrong to dig up some work he'd done to allow
LOGREC to reside on any DASD device type that the OS has general VTOC
and data set support for.
He sent them to me to package up, and so accordingly I can announce 3
new USERMODs which each update a module in order to provide generalized
and complete LOGREC DASD device type support.  There are 3 of them
because there are 3 different FMIDs involved.
ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC
I/O for EREP.
They can be downloaded from
http://www.prycroft6.com.au/vs2mods/index.html#zp60035
Cheers,
Greg

I tested the mods

ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC

on my test Moseley system.

They work correctly, Greg, and I had been able to
generate (STAGE2) an MVS3.8j over a 3380 RESVOL, for
what I can see, following the Moseley procedure
from an MVS3.8j with the mods installed over
the Morrison mods (with a minor change in SYS1.AGENLIB(SGIGG500)).

Unfortunately the result can't IPL:

IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2
HHC1C001A Enter input for console device 0009
/
IEA326I LOCATE FAILED FOR SYS1.LINKLIB
HHCCP011I CPU0000: Disabled wait state

while there is not any problem with SYS1.LINKLIB
or SYS1.NUCLEUS(SYSCATLG) on the 3380, for what
I can see from the generation output listings.

It seems I got trapped in the problem (4) found
by Kevin Leoanard long ago:

http://permalink.gmane.org/gmane.comp.emulators.turnkey-mvs/3748

4. Item 3 is not currently relevant because NIP VSAM
catalog support has device-dependent problems that cause
it to fail to locate catalog entries if the master catalog
is on a D/T3375, 3380 or 3390. Once the system is up,
ordinary system access to a D/T3375, 3380 or 3390 catalog
works fine. I've looked at this but have no fix.

But DIP works correctly:

18.55.01 JOB 19 IFC001I D=3380 N=0E F=01090000 L=010A0004 S=0109000002 DIP COMPLETE

It looks we are a step forward to IPL a 3380 RESVOL ;-)

Peppe.

[[e-mail] [H390-MVS]]

The fix for the wait00A is here:

http://www.j76.org/vs2/m096220.zip

and the cover letter describing it is here:

http://www.j76.org/vs2/m096220.txt

The problem is a bug in NIP's LOCATE simulation which incorrectly uses the catalog index component CI size instead of the data component CI size when calculating the RBA of a data component record. That's not a problem as long as index and data components both have the same CI size, as is the case with a 3350 or earlier DASD. For 3375, 3380 and 3390 DASD, IDCAMS chooses a different size for each component, which is what exposes the error.

--
Kevin

[Joe Monk [e-mail] [H390-MVS]]

Kevin,

Do you happen to have the M096500 mod that is described in the DAS102 mods
on your site?

Joe

Post by hercules-***@j76.org [H390-MVS]
http://www.j76.org/vs2/m096220.zip
http://www.j76.org/vs2/m096220.txt
The problem is a bug in NIP's LOCATE simulation which incorrectly uses the
catalog index component CI size instead of the data component CI size when
calculating the RBA of a data component record. That's not a problem as
long as index and data components both have the same CI size, as is the
case with a 3350 or earlier DASD. For 3375, 3380 and 3390 DASD, IDCAMS
chooses a different size for each component, which is what exposes the
error.
--
Kevin

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Well, Kevin ... it definitely works ;-)

I've still some fix to apply to my 3380 Moseley SYSGEN,
but it definitely IPL and JES2 starts with its datasets
still on a 3350 (JES2 doesn't seems to like to have
its datasets on a 3380, should be expected I think).

I had to IEBCOPY SYS1.NUCLEUS(IEAVNP12) from the
the system I used to SYSGEN to the generated system
(m096220 should be applied to the system in SYSGEN, I guess),
but it definitely IPL from a 3380.

Wow, a BIG, BIG thank you, Kevin!

The door is open ... now ...

Peppe.

Post by Joe Monk ***@gmail.com [H390-MVS]
Kevin,
Do you happen to have the M096500 mod that is described in the DAS102 mods
on your site?
Joe

Post by hercules-***@j76.org [H390-MVS]
http://www.j76.org/vs2/m096220.zip
http://www.j76.org/vs2/m096220.txt
The problem is a bug in NIP's LOCATE simulation which incorrectly uses the
catalog index component CI size instead of the data component CI size when
calculating the RBA of a data component record. That's not a problem as
long as index and data components both have the same CI size, as is the
case with a 3350 or earlier DASD. For 3375, 3380 and 3390 DASD, IDCAMS
chooses a different size for each component, which is what exposes the
error.
--
Kevin

[[e-mail] [H390-MVS]]

---In H390-***@yahoogroups.com, <***@...> wrote :

Thanks Kevin for finding and fixing
that MVS 3.8j bug.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I've still some fix to apply to my 3380 Moseley SYSGEN,
but it definitely IPL

It would be really great to see MVS 3.8j+
using nothing but 3390 disks. Does what
you have now only work on 3380 or does
it also work on 3390?

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
and JES2 starts with its datasets
still on a 3350 (JES2 doesn't seems to like to have
its datasets on a 3380, should be expected I think).

I don't think it should be "expected". I would
expect applications to be using standard
MVS calls to read/write data, and the underlying
disk should not be known or of interest to them.

I believe we have the proper source code to
JES2, right? If so, maybe it can be debugged
and fixed. Maybe you can show what error
you are getting from JES2 when using a 3380?

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
The door is open ... now ...

The door is open for you to do what? ie
what are you trying to achieve? A pure
3380 system or a stand-alone 3380
disk pack to IPL because you need more
data or what?

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Thanks Kevin for finding and fixing
that MVS 3.8j bug.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I've still some fix to apply to my 3380 Moseley SYSGEN,
but it definitely IPL

It would be really great to see MVS 3.8j+
using nothing but 3390 disks. Does what
you have now only work on 3380 or does
it also work on 3390?

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
and JES2 starts with its datasets
still on a 3350 (JES2 doesn't seems to like to have
its datasets on a 3380, should be expected I think).

I don't think it should be "expected". I would
expect applications to be using standard
MVS calls to read/write data, and the underlying
disk should not be known or of interest to them.

I believe we have the proper source code to
JES2, right? If so, maybe it can be debugged
and fixed. Maybe you can show what error
you are getting from JES2 when using a 3380?

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
The door is open ... now ...

The door is open for you to do what? ie
what are you trying to achieve? A pure
3380 system or a stand-alone 3380
disk pack to IPL because you need more
data or what?

BFN. Paul.

---

Paul, I've no idea if a 3390 would work.
I had the env ready for a 3380 and I tested
the Kevin's mod on what I had ready.

I may test a 3390 SYSGEN in the same env,
but I've to make a set of changes on my
SYSGEN jcl streams.

About JES2, I expected that from what
I've read about its checkpoint and spool
datasets, I may be plainly wrong and maybe
just some configuration may be needed.

The door is open to have a RESVOL on a
3380. It had been closed before, at least
for me.

I understand is a really small goal,
but it had been challenging enough for
my narrow knowledge of MVS sysgen.

Peppe.

[[e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
About JES2, I expected that from what
I've read about its checkpoint and spool
datasets, I may be plainly wrong and maybe
just some configuration may be needed.

Can you start by posting the error from
JES2 when its datasets reside on a 3380?

Thanks. Paul.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
About JES2, I expected that from what
I've read about its checkpoint and spool
datasets, I may be plainly wrong and maybe
just some configuration may be needed.

Can you start by posting the error from
JES2 when its datasets reside on a 3380?

Thanks. Paul.

--

In the hurry of testing IPL I didn't saved
the error.

Beside that, JES2 was complaining about
not enough tracks in its SYS1.HASPCKPT
checkpoint dataset on my 3380 volume.

The dataset was there, 50 3380 cylinders
allocated.

So, I guess, or something is wrong in
way JES2 check the dataset or JES2
configuration is not suitable for a 3380
dataset.

I bet for the first :-)

Peppe.

[[e-mail] [H390-MVS]]

Do you happen to have the M096500 mod that is described in the DAS102 mods on your site?

Yes. I'll put it here:

http://www.j76.org/vs2/m096500.txt

It's just the MCS and content, it doesn't have JCL. Also note it's just the DIP piece; I never made it to the other LOGREC-related elements.

Where is all this from? At one point, I rewrote and updated the MVS DASD mods. Unfortunately a couple of things (including those LOGREC pieces) didn't get finished, and the whole project didn't make it through the packaging stage. I'll try to see what can be salvaged from what there is.

One thing that needs to be salvaged is fixes for stage 1 macro assembly errors. Specifying a newer DASD type in GENERATE RESVOL produces errors. The resulting stage 2 JCL deck may or may not be OK, I never tried it. I just fixed it. The fix needs to be repackaged as corrective service.

The other thing I never figured out is how to install a new level of DASD mods on top of the old level. Normally you never accept usermods, but some of the DASD mods had to be accepted because the elements they hit are in DLIBs. So it's not possible to restore the existing mods.

Does what you have now only work on 3380 or does it also work on 3390?

What there is will work for 3375, 3380 or 3390. As has been noted, JES2 has potential DASD architecture dependencies that have never been addressed. The other big thing preventing a complete 3380 or 3390 MVS environment is ASM, which definitely has architecture dependencies. I'm not an ASM guy. If there is someone out there who is, by all means jump in.

I believe we have the proper source code to JES2, right?

Yes. JES2 4.1 is still shipped in source. The source is in SYS1.HASPSRC.

At one time, I had built a 3390 MVS system, but I can't find it. It's probably around here somewhere....

--
Kevin

[[e-mail] [H390-MVS]]

Post by hercules-***@j76.org [H390-MVS]
As has been noted, JES2 has potential DASD
architecture dependencies that have never
been addressed. The other big thing preventing
a complete 3380 or 3390 MVS environment is
ASM, which definitely has architecture dependencies.
At one time, I had built a 3390 MVS system, but
I can't find it.

Hi Kevin. How do you reconcile the above
two statements? ie how did you build a
3390 system without ASM (whatever that
is - presumably not "assembler")) and
JES2 fixes?

Thanks. Paul.

[[e-mail] [H390-MVS]]

Post by hercules-***@j76.org [H390-MVS]
The other thing I never figured out is how
to install a new level of DASD mods on top
of the old level. Normally you never accept
usermods, but some of the DASD mods had
to be accepted because the elements they
hit are in DLIBs. So it's not possible to
restore the existing mods.

Also, could you elaborate on this issue?

Are you saying that Jim Morrison's mods
were accepted, and that is causing you
problems?

Don't we have the pre-Jim version of
MVS 3.8j to work from if that is an issue?

Perhaps we need an automated build
process to go from the original IBM
tapes to the version of MVS distributed
by TK4-. Note that I have a script called
runmvs to do automation, but it was
designed to run on a system running
JES2. Not sure what is required to
automate a system that doesn't yet
have JES2, which is presumably the
case in the early stages of building MVS.

Maybe Peppe could be the builder as
he seems to be pretty keen on that. :-)

BFN. Paul.

[Joe Monk [e-mail] [H390-MVS]]

Kevin,

Thanks a lot!

One of the things that Peppe and I were trying is to build a system WITHOUT
the morrison mods.

Both of us use the moseley system...

With your DAS102 mods, now that we have this missing piece, we might
actually be able to do it...

Joe

Post by Joe Monk ***@gmail.com [H390-MVS]
Do you happen to have the M096500 mod that is described in the DAS102

mods on your site?
http://www.j76.org/vs2/m096500.txt
It's just the MCS and content, it doesn't have JCL. Also note it's just
the DIP piece; I never made it to the other LOGREC-related elements.
Where is all this from? At one point, I rewrote and updated the MVS DASD
mods. Unfortunately a couple of things (including those LOGREC pieces)
didn't get finished, and the whole project didn't make it through the
packaging stage. I'll try to see what can be salvaged from what there is.
One thing that needs to be salvaged is fixes for stage 1 macro assembly
errors. Specifying a newer DASD type in GENERATE RESVOL produces errors.
The resulting stage 2 JCL deck may or may not be OK, I never tried it. I
just fixed it. The fix needs to be repackaged as corrective service.
The other thing I never figured out is how to install a new level of DASD
mods on top of the old level. Normally you never accept usermods, but some
of the DASD mods had to be accepted because the elements they hit are in
DLIBs. So it's not possible to restore the existing mods.

Post by Joe Monk ***@gmail.com [H390-MVS]
Does what you have now only work on 3380 or does it also work on 3390?

What there is will work for 3375, 3380 or 3390. As has been noted, JES2
has potential DASD architecture dependencies that have never been
addressed. The other big thing preventing a complete 3380 or 3390 MVS
environment is ASM, which definitely has architecture dependencies. I'm
not an ASM guy. If there is someone out there who is, by all means jump in.

Post by Joe Monk ***@gmail.com [H390-MVS]
I believe we have the proper source code to JES2, right?

Yes. JES2 4.1 is still shipped in source. The source is in SYS1.HASPSRC.
At one time, I had built a 3390 MVS system, but I can't find it. It's
probably around here somewhere....
--
Kevin

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Joe Monk ***@gmail.com [H390-MVS]
Kevin,
Thanks a lot!
One of the things that Peppe and I were trying is to build a system WITHOUT
the morrison mods.
Both of us use the moseley system...
With your DAS102 mods, now that we have this missing piece, we might
actually be able to do it...
Joe

If you succeed, Joe, please keep us (read at leas me ;)
informed.

Peppe.

[Joe Monk [e-mail] [H390-MVS]]

No problemo amigo!

Joe

Post by Joe Monk ***@gmail.com [H390-MVS]

Post by Joe Monk ***@gmail.com [H390-MVS]
Kevin,
Thanks a lot!
One of the things that Peppe and I were trying is to build a system

WITHOUT

Post by Joe Monk ***@gmail.com [H390-MVS]
the morrison mods.
Both of us use the moseley system...
With your DAS102 mods, now that we have this missing piece, we might
actually be able to do it...
Joe

If you succeed, Joe, please keep us (read at leas me ;)
informed.
Peppe.

[[e-mail] [H390-MVS]]

One of the things that Peppe and I were trying is to build a system WITHOUT the morrison mods.

Good luck.

One thing I've found today while looking at a "corrective" fix to the old DASD mods is that the mods to the GENERATE macro got regressed on the TK3/TK4 DLIBs. Apparently PTF UZ84429 hit GENERATE, but it wouldn't go on because of the DASD usermods. So it looks like someone edited the MCS for UZ84429 to make it supersede the usermods. Now SMP thinks the DASD mods are there, but accepting UZ84429 physically removed them. So if you specify "3380" or "3390" on the GENERATE macro RESVOL parameter, it produces a "DEVICE TYPE INVALID" error. I'll add it back.

--
Kevin

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by hercules-***@j76.org [H390-MVS]

One of the things that Peppe and I were trying is to build a system WITHOUT the morrison mods.

Good luck.
One thing I've found today while looking at a "corrective" fix to the
old DASD mods is that the mods to the GENERATE macro got regressed on
the TK3/TK4 DLIBs. Apparently PTF UZ84429 hit GENERATE, but it wouldn't
go on because of the DASD usermods. So it looks like someone edited the
MCS for UZ84429 to make it supersede the usermods. Now SMP thinks the
DASD mods are there, but accepting UZ84429 physically removed them. So
if you specify "3380" or "3390" on the GENERATE macro RESVOL parameter,
it produces a "DEVICE TYPE INVALID" error. I'll add it back.

That is exactly the error I get from

SYS1.AGENLIB(SGIGG500)

on my Moseley generated MVS3.8j, with ptfs.het
tape ACCEPTED, but mostly not APPLIED.

The Morrison tape j90009.het is ACCEPTED:

ACCEPT S(M023000
M023100
M023200 M023201 M023202 M023203 M023204
M023300 M023301 M023302
M023400 M023401 M023402 M023403 M023404 M023405
M024001
M024101
M024205 M024206 M024207
M024303 M024304 M024305
M024406 M024407 M024408
) USERMODS NOAPPLY DIS(WRITE) COMPRESS(ALL)

I had to modify SYS1.AGENLIB(SGIGG500) from:

AIF ('&UNIT' NE '3380').N3380 +3380 ?? MVS38J
MNOTE *,'SGIGG500 - 3380 untested - MVS38J' MVS38J
CONVERT TO=EBCDIC,DIGITS=1,VALUE=0E MVS38J

to:

AIF ('&UNIT' NE '3380').N3380 +3380 ?? MVS38J
&LINE SETC '&LINE'.' ' + YES - APPEND X'0E' MVS38J
AGO .END + AND LEAVE MVS38J

to allow STAGE1 to complete successfully for a RESVOL on a 3380.

Note the "MVS38J" tag on that lines, I guess it came from
the Morrison usermods.

My 2 cents, Peppe.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by Greg Price ***@optusnet.com.au [H390-MVS]
Hi,
It seems Peppe's recent point about IFCDIP00 not handling all device
types has prompted Tom Armstrong to dig up some work he'd done to allow
LOGREC to reside on any DASD device type that the OS has general VTOC
and data set support for.
He sent them to me to package up, and so accordingly I can announce 3
new USERMODs which each update a module in order to provide generalized
and complete LOGREC DASD device type support.  There are 3 of them
because there are 3 different FMIDs involved.
ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC
I/O for EREP.
They can be downloaded from
http://www.prycroft6.com.au/vs2mods/index.html#zp60035
Cheers,
Greg

I tested the mods
ZP60035 for FMID EBB1102 - this updates IFBSVC76 which is the LOGREC writer.
ZP60036 for FMID FBB1221 - this updates IFCDIP00 which initializes LOGREC.
ZP60037 for FMID EER1400 - this updates IFCIOHND which handles LOGREC
on my test Moseley system.
They work correctly, Greg, and I had been able to
generate (STAGE2) an MVS3.8j over a 3380 RESVOL, for
what I can see, following the Moseley procedure
from an MVS3.8j with the mods installed over
the Morrison mods (with a minor change in SYS1.AGENLIB(SGIGG500)).
IEA101A SPECIFY SYSTEM PARAMETERS FOR RELEASE 03.8 .VS2
HHC1C001A Enter input for console device 0009
/
IEA326I LOCATE FAILED FOR SYS1.LINKLIB
HHCCP011I CPU0000: Disabled wait state
while there is not any problem with SYS1.LINKLIB
or SYS1.NUCLEUS(SYSCATLG) on the 3380, for what
I can see from the generation output listings.
It seems I got trapped in the problem (4) found
http://permalink.gmane.org/gmane.comp.emulators.turnkey-mvs/3748
4. Item 3 is not currently relevant because NIP VSAM
catalog support has device-dependent problems that cause
it to fail to locate catalog entries if the master catalog
is on a D/T3375, 3380 or 3390. Once the system is up,
ordinary system access to a D/T3375, 3380 or 3390 catalog
works fine. I've looked at this but have no fix.
18.55.01 JOB 19 IFC001I D=3380 N=0E F=01090000 L=010A0004 S=0109000002 DIP COMPLETE
It looks we are a step forward to IPL a 3380 RESVOL ;-)
Peppe.

A side note, and question, about ZP60036.

At line 2105 of ZP60036.JCL, in the assembler code
of IFCDIP00, there is this line of code:

BASR R14,R15 CONVERT TTRN TO MBBCCHHR 00142200

which uses the BASR assembler mnemonic.

This single line of code requires to install ZP60025
to let IFOX00 to support this instruction.

I'm wondering if it would be possible to replace BASR with BALR
to avoid the dependency on ZP60025.

In alternative shouldn't the ZP60025 dependency appear in
the ZP60036 user mod as a PRE()?

Apologies for the naive question, Peppe

[[e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I'm wondering if it would be possible to replace BASR with BALR
to avoid the dependency on ZP60025.

Sounds reasonable, that's why I stick
with BALR for now too. On the other
hand, it's also reasonable for programmers
to expect BASR to be available.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In alternative shouldn't the ZP60025 dependency appear in
the ZP60036 user mod as a PRE()?

Not sure the best way to do things, but you
can also solve your problem by putting this:

http://mvs380.cvs.sourceforge.net/viewvc/mvs380/mvs380/source/maclib/basr.mac?view=markup

into SYS1.MACLIB (or any other library you
choose to use).


BFN. Paul.

[Greg Price [e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
This single line of code requires to install ZP60025
to let IFOX00 to support this instruction.

That's one solution but there are others.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I'm wondering if it would be possible to replace BASR with BALR
to avoid the dependency on ZP60025.

Yes, you can change your copy before submitting the job.
:)

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In alternative shouldn't the ZP60025 dependency appear in
the ZP60036 user mod as a PRE()?

Different FMID, so there's a bit of IFREQ fun you can have if you so choose.

Cheers,
Greg




------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Greg Price ***@optusnet.com.au [H390-MVS]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
This single line of code requires to install ZP60025
to let IFOX00 to support this instruction.

That's one solution but there are others.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I'm wondering if it would be possible to replace BASR with BALR
to avoid the dependency on ZP60025.

Yes, you can change your copy before submitting the job.
:)

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In alternative shouldn't the ZP60025 dependency appear in
the ZP60036 user mod as a PRE()?

Different FMID, so there's a bit of IFREQ fun you can have if you so choose.
Cheers,
Greg

Understood, Greg.

What I don't understand is why distributing ZP60036
with this single BASR, if a BASL is enough.

This usermod makes sense only for MVS3.8j which
doesn't have DIP support for 3380/3390 and which
doesn't, as distributed, assemble the BASR mnemonic.

Nobody is going to install this usermod on a version
of MVS different from MVS3.8j, isn't?

Peppe.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]

Post by Greg Price ***@optusnet.com.au [H390-MVS]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
This single line of code requires to install ZP60025
to let IFOX00 to support this instruction.

That's one solution but there are others.

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
I'm wondering if it would be possible to replace BASR with BALR
to avoid the dependency on ZP60025.

Yes, you can change your copy before submitting the job.
:)

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
In alternative shouldn't the ZP60025 dependency appear in
the ZP60036 user mod as a PRE()?

Different FMID, so there's a bit of IFREQ fun you can have if you so choose.
Cheers,
Greg

Understood, Greg.
What I don't understand is why distributing ZP60036
with this single BASR, if a BASL is enough.
This usermod makes sense only for MVS3.8j which
doesn't have DIP support for 3380/3390 and which
doesn't, as distributed, assemble the BASR mnemonic.
Nobody is going to install this usermod on a version
of MVS different from MVS3.8j, isn't?
Peppe.

Ops, s/BASL/BALR/, of course, apologies.
Peppe.

[Greg Price [e-mail] [H390-MVS]]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
What I don't understand is why distributing ZP60036
with this single BASR, if a BASL is enough.
This usermod makes sense only for MVS3.8j which
doesn't have DIP support for 3380/3390 and which
doesn't, as distributed, assemble the BASR mnemonic.

Most of the potential "customers" already have the mod to IFOX on from
the various TK packages.

In any event, since I no longer use - or even have access to - a machine
which does not have BAS and BASR functionality, I dropped BAL and BALR
from my instruction repertoire some years back.

Further, dumps from abends in my code may likely come to me for
diagnosis, and I want the dump to be as clear/clean as possible. Even if
AM31 is known to not be involved in one diagnosis scenario, the habits
and expectations gained from AM31 and AM64 dump analysis bleed across,
and so I proceed on the basis that simplicity of data assists rapidity
of diagnosis.

It is only mavericks such as yourself sightseeing down abandoned old
trails to see where the early explorers went who will come across these
artefacts and incongruities, but for such people any problems like these
are easy to solve and are more like entertainments than hardships.

So, enjoy the journey...
:)


But, in all my bluster, I had forgotten that these particular mods were
coded by Tom and not by me at all.  Since they appear to work very well,
I am very happy to distribute them from my web site.


Cheers,
Greg




------------------------------------

------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-MVS/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/H390-MVS/join
(Yahoo! ID required)

<*> To change settings via email:
H390-MVS-***@yahoogroups.com
H390-MVS-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
H390-MVS-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Greg Price ***@optusnet.com.au [H390-MVS]

Post by Giuseppe Vitillaro ***@vitillaro.org [H390-MVS]
What I don't understand is why distributing ZP60036
with this single BASR, if a BASL is enough.
This usermod makes sense only for MVS3.8j which
doesn't have DIP support for 3380/3390 and which
doesn't, as distributed, assemble the BASR mnemonic.

Most of the potential "customers" already have the mod to IFOX on from
the various TK packages.
In any event, since I no longer use - or even have access to - a machine
which does not have BAS and BASR functionality, I dropped BAL and BALR
from my instruction repertoire some years back.
Further, dumps from abends in my code may likely come to me for
diagnosis, and I want the dump to be as clear/clean as possible. Even if
AM31 is known to not be involved in one diagnosis scenario, the habits
and expectations gained from AM31 and AM64 dump analysis bleed across,
and so I proceed on the basis that simplicity of data assists rapidity
of diagnosis.
It is only mavericks such as yourself sightseeing down abandoned old
trails to see where the early explorers went who will come across these
artefacts and incongruities, but for such people any problems like these
are easy to solve and are more like entertainments than hardships.
So, enjoy the journey...
:)

Yep, I will, Greg ;-)

You know, sometime, even in dark and alone tracks
some "lost gem" may still be found along the way ;-)

Post by Greg Price ***@optusnet.com.au [H390-MVS]
But, in all my bluster, I had forgotten that these particular mods were
coded by Tom and not by me at all.  Since they appear to work very well,
I am very happy to distribute them from my web site.

And I'm grateful for your and Tom's efforts!

Thanks for the taking the time of an explanation, Greg,
appreciated.

Peppe.

[[e-mail] [H390-MVS]]

When I am coding I only use BAS and BASR because I much prefer to have a clean hi-order byte in the register containing the return address as Greg made in his post. Except for the rare occasion when a program wants to save the ILC, CC and Program Mask in the 370 environment I believe that BAS and BASR are the preferable instructions these days.
Usually I automatically convert all BAL and BALR instructions to BAS and BASR respectively when I update a module. However I recognize that there are some people who have not upgraded IFOX00 with the various mods that are available. To ensure that the LOGREC mods would be successfully applied on any system I converted the BAS and BASR instructions back to their original BAL and BALR opcodes. I must have missed one which Peppe discovered.

The formatting of LOGREC and the values placed in the LOGREC header record cannot be considered in isolation. The code in SVC 76 (IFBSVC76/IFBSTAT) performs track space calculations using the values from the LOGREC header record to determine if a record to be written can be placed on the current track or the next track must be used. The code in the unmodified version of the SVC is primitive in that it adds a value (called a subtraction constant) from the table below to the length of the record to be written to LOGREC.
SUBCONST DC XL2'10' TABLE OF SUBTRACTION CONSTANTS
DC AL2(085) 2311 SUBTRACT CONSTANT
DC AL2(133) 2301 SUBTRACT CONSTANT
DC AL2(108) 2303 SUBTRACT CONSTANT
DC AL2(085) 2302 SUBTRACT CONSTANT
DC AL2(107) 2321 SUBTRACT CONSTANT
DC AL2(432) 2305-I SUBTRACT CONSTANT
DC AL2(198) 2305-II SUBTRACT CONSTANT
DC AL2(122) 2314 SUBTRACT CONSTANT
DC AL2(135) 3330 SUBTRACT CONSTANT
DC AL2(167) 3340 SUBTRACT CONST
DC AL2(183) 3350 SUBTRACT CONST
DC AL2(000) DUMMY SUBTRACT CONST
DC AL2(135) 3330-1 SUBTRACT CONST
This combined value is added to the cumulative track balance number in the header record and the result compared to the 90% track capacity figure from the LOGREC header record. If the 90% track capacity number is exceeded then the track is deemed full and writing advances to the next track.
This method is not particularly accurate but is acceptable for the DASD types listed above. However for the newer 3375, 3380 and 3390 DASD which are modulo devices, ie FBA DASD in disguise, the track balance calculation required is more complex. Not all records written to LOGREC are short OBR type records. Software Error Records are significantly longer so a single value added to the record length may result in an incorrect calculation. The end result could be an attempt to write a record on a track where there is insufficient room. The unmodified version of the SVC, writing to 3380 or 3390 DASD will pick up a trash value for the subtraction constant resulting in an invalid track balance calculation. For 3375 DASD the value will be zero as we can see from the table above.
The ZP60035 moded version of SVC 76 uses the MVS TRKCALC service to correctly calculate the track balance for older type DASD and the new modulo 3375, 3380 and 3390 DASD.

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Thank you so much Thomas. I really appreciated your post.

I'm going to apply in any case ZP60025 for BASR support,
in my new-moseley, but logic suggested to me this BASR
was in some way "misplaced". It created a dependency which
is not really needed and that is not easy to code as a prereq,
from the Greg's comments.

Glad to read was just a "missed" BASR ;-)

I apologize for my naivness in my comments, my post
should look really rough to people with deep MVS
experience.

But ... well ... I'm learning ... slowly ... but
I'm learning ;-)

Peppe.

Post by ***@yahoo.com [H390-MVS]
When I am coding I only use BAS and BASR because I much prefer to have a
clean hi-order byte in the register containing the return address as
Greg made in his post. Except for the rare occasion when a program wants
to save the ILC, CC and Program Mask in the 370 environment I believe
that BAS and BASR are the preferable instructions these days. Usually I
automatically convert all BAL and BALR instructions to BAS and BASR
respectively when I update a module. However I recognize that there are
some people who have not upgraded IFOX00 with the various mods that are
available. To ensure that the LOGREC mods would be successfully applied
on any system I converted the BAS and BASR instructions back to their
original BAL and BALR opcodes. I must have missed one which Peppe
discovered.
The formatting of LOGREC and the values placed in the LOGREC header
record cannot be considered in isolation. The code in SVC 76
(IFBSVC76/IFBSTAT) performs track space calculations using the values
from the LOGREC header record to determine if a record to be written can
be placed on the current track or the next track must be used. The code
in the unmodified version of the SVC is primitive in that it adds a
value (called a subtraction constant) from the table below to the length
of the record to be written to LOGREC. SUBCONST DC XL2'10' TABLE OF
SUBTRACTION CONSTANTS
DC AL2(085) 2311 SUBTRACT CONSTANT
DC AL2(133) 2301 SUBTRACT CONSTANT
DC AL2(108) 2303 SUBTRACT CONSTANT
DC AL2(085) 2302 SUBTRACT CONSTANT
DC AL2(107) 2321 SUBTRACT CONSTANT
DC AL2(432) 2305-I SUBTRACT CONSTANT
DC AL2(198) 2305-II SUBTRACT CONSTANT
DC AL2(122) 2314 SUBTRACT CONSTANT
DC AL2(135) 3330 SUBTRACT CONSTANT
DC AL2(167) 3340 SUBTRACT CONST
DC AL2(183) 3350 SUBTRACT CONST
DC AL2(000) DUMMY SUBTRACT CONST
DC AL2(135) 3330-1 SUBTRACT CONST
This combined value is added to the cumulative track balance number in
the header record and the result compared to the 90% track capacity
figure from the LOGREC header record. If the 90% track capacity number
is exceeded then the track is deemed full and writing advances to the
next track. This method is not particularly accurate but is acceptable
for the DASD types listed above. However for the newer 3375, 3380 and
3390 DASD which are modulo devices, ie FBA DASD in disguise, the track
balance calculation required is more complex. Not all records written to
LOGREC are short OBR type records. Software Error Records are
significantly longer so a single value added to the record length may
result in an incorrect calculation. The end result could be an attempt
to write a record on a track where there is insufficient room. The
unmodified version of the SVC, writing to 3380 or 3390 DASD will pick up
a trash value for the subtraction constant resulting in an invalid track
balance calculation. For 3375 DASD the value will be zero as we can see
from the table above. The ZP60035 moded version of SVC 76 uses the MVS
TRKCALC service to correctly calculate the track balance for older type
DASD and the new modulo 3375, 3380 and 3390 DASD.

[Greg Price [e-mail] [H390-MVS]]

Post by ***@yahoo.com [H390-MVS]
I must have missed one which Peppe discovered.

FYI, ZP60036 has now been reissued on the web site with the BASR changed
to BALR.

Cheers,
Greg

[Giuseppe Vitillaro [e-mail] [H390-MVS]]

Post by Greg Price ***@optusnet.com.au [H390-MVS]

Post by ***@yahoo.com [H390-MVS]
I must have missed one which Peppe discovered.

FYI, ZP60036 has now been reissued on the web site with the BASR changed
to BALR.
Cheers,
Greg

Great!

Thanks, Peppe.

[[e-mail] [H390-MVS]]

No I'm not back and probably won't be available for months.

3380-2 may be better for some applications than 3390-2 ?

3380-2 26550 tracks and 1.26GB maximum disk space.
9345-2 32340 tracks and 1.51GB maximum disk space.
3390-1 16695 tracks and .946GB maximum disk space.
3390-2184 32760 tracks and 1.856GB maximum disk
space fits MVS 3.8j but is non-standard.

3390-2 33390 tracks and 1.89GB exceeds the 32767
maximum that MVS 3.8j handles properly. Some of the
places to increase the limit to 65536 tracks have been
known for many years but only one done. If others done,
3390-3 50085 tracks and 2.84GB maximum disk space
would work and
3390-4369 65536 tracks and 3.7GB maximum disk
space would be non-standard but would work.

Note: The Morrison modded Becker mods did not include
either 9345 or 2311. 9345 device-type replaced a previous
use device-type.

X'2001' - 2311 disk storage drive
X'2002' - 2301 Parallel file
X'2003' - 2303 serial drum
X'2004' - 9345 disk storage, previously 2302 disk
X'2005' - 2321 data cell
X'2006' - 2305 drum (Zeus) model 1
X'2007' - 2305 drum (Zeus) model 2
X'2008' - 2314 disk
X'2009' - 3330 disk (Merlin)
X'200A' - 3340 disk (Winchester)
X'200B' - 3350 disk (Madrid)
X'200C' - 3375 disk
X'200D' - 3330-1 disk (Iceberg)
X'200E' - 3380 disk
X'200F' - 3390 disk