[H390-MVS] Help with REVIEW/REVEDIT - "unable to allocate unit"

['Matthew R. Wilson' [e-mail] [H390-MVS]]

Hello,

When I use newer versions of REVIEW, I'm having a problem: when I edit
a dataset, the MVS 3.8 console says:

IEF244I MWILSON IKJACCNT IKJACCNT - UNABLE TO ALLOCATE 1 UNIT(S)
AT LEAST 1 OFFLINE UNIT(S) NEEDED.
IEF489I MWILSON - 1 UNIT(S) NEEDED FOR SYS00007
IEF247I MWILSON - 181,182,183,184,185,186,187,280,281,282,283,284 OFFLINE
IEF247I MWILSON - 285,286,287,380,381,382,383,384,385,386,387 OFFLINE
IEF238D MWILSON - REPLY DEVICE NAME OR 'CANCEL'.

I reply with 'cancel', and in the TSO session REVEDIT gives a warning
"UNDO ALLOC FAILED" but I am otherwise able to continue editing and
saving the dataset member.

Older versions of REVIEW (e.g. 45.3) don't seem to give me this problem.

If I run the 'REVINIT' CLIST that review ships with, I get the same
behavior and the REVPROF PDS isn't created. If I manually create a
REVPROF dataset under my user's HLQ, then REVINIT executes cleanly.
But even after creating REVPROF, I still have the same problem when
editing a dataset. So I'm not sure if it's at all related or not. It
looks like it's referring to a PROFATTR attribute, so maybe I'm
missing a definition (or a correct definition) of that somewhere?

Without knowing too much about this mainframe stuff... it seems like
REVEDIT is trying to allocate a dataset that is defined somewhere, and
I need to change that definition to match available locations on my
system, but I'm not sure how to figure out what's causing the
allocation that is failing.

(This is in a system I built using Jay Moseley's MVS installation
instructions; the version of REVIEW he includes doesn't cause this
problem but if I install 48.3 I have the problem.)

I'd appreciate any hints as to how to investigate further.

Thank you,
Matthew

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

I ran into this problem also...

There is a change that requires an undo dataset. I think its like
REVEDIT.BACKUP or something similar

Joe

Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
Hello,
When I use newer versions of REVIEW, I'm having a problem: when I edit
IEF244I MWILSON IKJACCNT IKJACCNT - UNABLE TO ALLOCATE 1 UNIT(S)
AT LEAST 1 OFFLINE UNIT(S) NEEDED.
IEF489I MWILSON - 1 UNIT(S) NEEDED FOR SYS00007
IEF247I MWILSON - 181,182,183,184,185,186,187,280,281,282,283,284 OFFLINE
IEF247I MWILSON - 285,286,287,380,381,382,383,384,385,386,387 OFFLINE
IEF238D MWILSON - REPLY DEVICE NAME OR 'CANCEL'.
I reply with 'cancel', and in the TSO session REVEDIT gives a warning
"UNDO ALLOC FAILED" but I am otherwise able to continue editing and
saving the dataset member.
Older versions of REVIEW (e.g. 45.3) don't seem to give me this problem.
If I run the 'REVINIT' CLIST that review ships with, I get the same
behavior and the REVPROF PDS isn't created. If I manually create a
REVPROF dataset under my user's HLQ, then REVINIT executes cleanly.
But even after creating REVPROF, I still have the same problem when
editing a dataset. So I'm not sure if it's at all related or not. It
looks like it's referring to a PROFATTR attribute, so maybe I'm
missing a definition (or a correct definition) of that somewhere?
Without knowing too much about this mainframe stuff... it seems like
REVEDIT is trying to allocate a dataset that is defined somewhere, and
I need to change that definition to match available locations on my
system, but I'm not sure how to figure out what's causing the
allocation that is failing.
(This is in a system I built using Jay Moseley's MVS installation
instructions; the version of REVIEW he includes doesn't cause this
problem but if I install 48.3 I have the problem.)
I'd appreciate any hints as to how to investigate further.
Thank you,
Matthew

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

Post by 'Matthew R. Wilson' ***@mattwilson.org [H390-MVS]
When I use newer versions of REVIEW, I'm having a problem: when I edit
IEF244I MWILSON IKJACCNT IKJACCNT - UNABLE TO ALLOCATE 1 UNIT(S)
AT LEAST 1 OFFLINE UNIT(S) NEEDED.
IEF489I MWILSON - 1 UNIT(S) NEEDED FOR SYS00007
IEF247I MWILSON - 181,182,183,184,185,186,187,280,281,282,283,284 OFFLINE
IEF247I MWILSON - 285,286,287,380,381,382,383,384,385,386,387 OFFLINE
IEF238D MWILSON - REPLY DEVICE NAME OR 'CANCEL'.

Any chance user ID MWILSON has the MOUNT attribute?

Since it is unlikely that you have lots of unmounted DASD volumes
needing to be mounted on a limited range of addresses as required, I
suggest that the dynamic allocation WTORs generated by your TSO sessions
can be largely eliminated by changing that attribute of your ID to NOMOUNT.

You might say that in a properly configured system the MOUNT attribute
should not cause a problem.  This well may be true if all of your
potential I/O devices are either online with permanently resident
volumes such that the allocation can be failed without reference to the
operator, or you have a software product which manages such things for
you.  In practice, if I have MOUNT and I mistype a volume serial number,
I soon wish I had NOMOUNT.

If you ever want to browse a tape data set on a tape volume with
standard labels, then you can pre-mount the tape, and AVR (Automatic
Volume Recognition) will allow the allocation to proceed without any
intervening demount, even if your ID has NOMOUNT.

From time to time, it may suit you to exploit the MOUNT attribute for a
specific exercise.  When this occurs for me, I just turn on MOUNT for
the current session, which is basically flipping a bit in protected
storage.  I recall that there is a CPSCB command somewhere (CBT?) which
would probably do the job, but of course I use IMON.

IM VB
from READY will see you browsing virtual storage.  Type in
MNT
and you have MOUNT, and type in
NMNT
and you have NOMOUNT.

This will flip the bit in storage, but will not affect the UADS
definition of your ID, so the next time you logon MNT/NMNT changes will
be forgotten.

With NOMOUNT, the allocation will still fail, but you won't have to wait
for "the operator" to reply.


The actual changes in REVIEW/RFE were brought about by someone
complaining that UNDO data sets were being allocated on volumes beyond
the control of the UNIT assigned in the TSO user's UADS definition.

To maximize the chances that an allocation for a new data set will
succeed, REVIEW/RFE used UNIT=SYSALLDA.  However, the ability to direct
these allocations seemed reasonable to me, and so changes were implemented.

As alluded to in the release notes at
http://www.prycroft6.com.au/REVIEW/revnotes.html#R48
under the R48.1 "Secondly" point, the UADS unit is now used for various
allocations.

(Under TSO, the user's UADS unit is the default UNIT used when no UNIT
is actually specified.  When data sets are referenced via the catalog,
the catalog entry supplies both the volume serial number and the UNIT,
which may be generic or esoteric, but is not a specific cua.)

While there is provision for retrying failed allocations with
UNIT=SYSALLDA for short-lived or small (or both) data sets, I decided to
not do that with UNDO/RECOVER data sets because they are not (what I
would call) small and they may not be short-lived.

So, make sure your TSO ID has a suitable UADS unit.  If you want it to
work all as before then simply make it SYSALLDA.  A better choice may be
to nominate a particular device type (such as 3350 or 3380 or 3390 or
whatever) so that the geometry of new data sets becomes more predictable.

If you have a particular esoteric unit for TSO users such as TSODA (to
quote a possible example) then you can use that.

Background for non-mainframers, and perhaps mainframers who are non-MVSers:

A "unit" is an I/O device.  In JCL use UNIT=cua where cua is 3 hex
digits which specifies the I/O device address.
(I used "cua" because that is short for "channel unit address". With XA
and later, "dev" replaced "cua" because the device number no longer
needs to encode any actual addressing.)

A "generic" unit is a recognized term for a device type such as
UNIT=3350 where 3350 is a type of DASD.  Generic units will include the
pool of I/O devices of that type.  System/360 devices are in the 2000s
and System/370 devices are in the 3000s.  Tapes are x4xx and disks are
x3xx.  This list does extend further, but if I try to do that I'll get
something wrong, but I'll hazard that x700 are communications (network)
devices.

An "esoteric" unit is an administrative creation (created at SYSGEN time
for MVS/370) such as TAPE or SYSDA or SORTWORK or WORKDA, etc. The
person doing the SYSGEN "makes up" these names and selects which I/O
devices are included in each.  Names such as SYSDA (disks), TAPE (tapes,
sometimes only round tapes) CART (square tapes) and SYSSQ (tapes and
disks) are often considered "well known" by convention. OS/VS (I think)
added SYSALLDA to automatically mean all DASD (disks) so this can be
used on (virtually) all systems, whereas SYSDA is a local creation which
may not even exist (which was the case where I worked first).

Data sets created with the name fully specified are "permanent" data
sets, even if they are deleted soon after creation.  Data sets created
with system-generated names are "temporary" data sets which cannot
(except for power failures, system crashes, etc.) exist beyond the end
of the job which created them.  DSN=&&MYDATA for example specifies a
temporary data set.

DASD volumes can have the PRIVATE, PUBLIC or STORAGE attribute. They can
be assigned this at IPL by the contents of the VATLSTxx member of
SYS1.PARMLIB, or in a MOUNT system command.  For example,
M 123,VOL=(SL,DISK01),USE=STORAGE
where M is short for MOUNT, 123 is the cua, SL means "standard labels",
DISK01 is the "volume serial number", and USE is as described.  MOUNT
can be used to change the attribute of a mounted volume.

PRIVATE volumes only get selected for new data sets when explicitly
coded (JCL example: VOL=SER=DISK01).
PUBLIC volumes will be used for new temporary data sets.
STORAGE volumes will be used for new permanent data sets.

ISTR that PUBLIC volumes can be used for new permanent data sets if
there are no STORAGE volumes, but I have not tested that recently.

Cheers,
Greg

['Matthew R. Wilson' [e-mail] [H390-MVS]]

Post by pricgren ***@yahoo.com [H390-MVS]
Any chance user ID MWILSON has the MOUNT attribute?

Yes--changing my user to NOMOUNT took care of the problem; editing now
opens up without requiring console intervention. Thank you!

And thank you *so* much for the extremely comprehensive answer and
other background material. I'm going to need to read it a couple times
to fully grok it, but it's really helpful as I learn more and more
about MVS.

Thanks again,
Matthew

[Vince Coen [e-mail] [H390-MVS]]

Hi Greg;


Do you have an up to date copy of the review manual in .doc or odf
formats available as I cannot see it on your website.

Vince
--
- IMPORTANT –

This email and the information in it may be confidential, legally privileged
and/or protected by law.
It is intended solely for the use of the person to whom it is addressed.
If you are not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium.

Please also delete all copies of this email & any attachments from your system.

If this is an encrypted email it is your responsibility to maintain the 1024
byte key system even for one-use keys. Once mail has been sent the sending key
is not kept and therefore a replacement mail cannot be resent.

We cannot guarantee the security or confidentiality of non encrypted email
communications.
We do not accept any liability for losses or damages that you may suffer as a
result of your receipt of this email including but not limited to computer
service or system failure, access delays or interruption, data non-delivery
or mis-delivery, computer viruses or other harmful components.

Copyright in this email and any attachments belongs to Applewood Computers.
Should you communicate with anyone at Applewood Computers by email,
you consent to us monitoring and reading any such correspondence.

Nothing in this email shall be taken or read as suggesting, proposing or
relating to any agreement concerted practice or other practice that could
infringe UK competition legislation (unless it is against Security
requirements).

This Email and its attachments (if any) are scanned for virii using Clamd
and ClamAV 0.99.4 or later (Linux x64).

Dykegrove Limited T/A Applewood Computers is a company registered in England
(no. 01681349) whose registered office is at Applewood House,
17 Stag Green Avenue, Hatfield, Hertfordshire, AL9 5EB, UK.

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

Post by Vince Coen ***@gmail.com [H390-MVS]
Do you have an up to date copy of the review manual in .doc or odf
formats available as I cannot see it on your website.

Sadly, no.

In fact, I don't even have an out-of-date manual for REVIEW.

I'm a programmer, so I don't do documentation.

Actually, sometimes I do, but then the people who tell me to do it are
paying my salary, so I feel I have to.

I've thought about it, and even made a small start once.  But then I
really didn't know how to structure it.

Still, not to worry - it's written in assembler, so it's all
self-documenting.

:)

Cheers,
Greg

PS  I try to keep the HELP members up to date, but of course, there's
probably more to know than just the commands.
:(

['Wally Mclaughlin' [e-mail] [H390-MVS]]

Greg -



"I'm a programmer, so I don't do documentation."



I don’t remember that line ever going over so well...



The trick, Greg, is to write a product that someone else has already documented - even if it was IBM!



Wally



From: H390-***@yahoogroups.com [mailto:H390-***@yahoogroups.com]
Sent: Saturday, September 1, 2018 2:10 PM
To: H390-***@yahoogroups.com
Subject: Re: [H390-MVS] Help with REVIEW/REVEDIT - "unable to allocate unit"

Post by Vince Coen ***@gmail.com [H390-MVS]
Do you have an up to date copy of the review manual in .doc or odf
formats available as I cannot see it on your website.

Sadly, no.

In fact, I don't even have an out-of-date manual for REVIEW.

I'm a programmer, so I don't do documentation.

Actually, sometimes I do, but then the people who tell me to do it are
paying my salary, so I feel I have to.

I've thought about it, and even made a small start once. But then I
really didn't know how to structure it.

Still, not to worry - it's written in assembler, so it's all
self-documenting.

:)

Cheers,
Greg

PS I try to keep the HELP members up to date, but of course, there's
probably more to know than just the commands.
:(