Official Home of the VTOC Command
Michael Cleary
I am trying to find the lastest level of the VTOC command.
I was using a copy that I have last week and didn't have enough room on the
command line to specify a long list of volume serial prefixes. I was merely
trying to map into an SMS storage group.
It would be nice if the VTOC command could be updated to allow for the
specification of SMS storage group.
Once we find the current level of the source is there a volunteer to make this
minor change to the program?
Cheers...
Michael
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Big Iron
Bill
John P Kalinich
wrote on 12/05/2008 10:03:04 AM:
> I am trying to find the lastest level of the VTOC command.
>
> I was using a copy that I have last week and didn't have enough room on
the
> command line to specify a long list of volume serial prefixes. I was
merely
> trying to map into an SMS storage group.
>
> It would be nice if the VTOC command could be updated to allow for the
> specification of SMS storage group.
>
> Once we find the current level of the source is there a volunteer tomake
this
> minor change to the program?
That would be file 112 on your www.cbttape.org dial. If your command line
isn't long enough, use option 6 or the CMDE interface. In batch, you can
continue the volume list for thousands of volumes/prefixes.
Regards,
John K
Michael Cleary
I was running in batch and had many other parms to specify and ran into the
TSO parm limit. :)
Is File 112 where you get your VTOC command from that you ship with the
PDS command?
Any enhancements to the PDS command in the works? I have V869.
Cheers...
Michael
Edward Jaffe
> Any enhancements to the PDS command in the works? I have V869.
>
For those of you coming to SHARE in Austin, March 1-6, check out this
session:
2811 MVS Freeware #1: System Utilities
Greg Price will be flying in from Australia to present the latest
information about REVIEW and PDS. According to the abstract, "He will
describe some of the advanced features that are often overlooked by new
users." If there's anything new planned for these utilities, let's hope
it gets implemented by then so Greg can present it! ;-) Along with
Greg, Dave Danner will present the latest on SYSOUT Retrieval Services
(SRS), updated to use facilities available in z/OS 1.9 and higher.
The off-list responses to my IBM-MAIN solicitation were as expected.
This is a topic of great interest to the z/OS community represented here
on IBM-MAIN. The SHARE MVS/SCP Project hopes to continue, in the future,
with similar sessions presented by the Shareware/Freeware product
authors/maintainers themselves.
And, as if that wasn't enough, Sam Knutson will be back to talk about
free MVS tools in:
2810 Fully Wired Hot Topics Austin City Limits Edition: Free MVS Tools
and Tips Update
If you've never been to this session, hold your breath. Sam talks
a-mile-a-minute and everyone walks away with a handful of DVDs--in this
case, filled with new CBT content updated just in time for SHARE in
Austin. Ride 'em, cowboy!
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Herring, Bobby
Productivity Center for Disk(TPC) software to work. It seems to mostly
work for the "dark side" people but we have not been able to get it to
work for the mainframe side. It doesn't show the volser of the volume.
It has something like CKD_0001. That's useless for our purposes.
Is anyone else using or trying to use the TPC product?
Thank you,
Bobby Herring
Texas Farm Bureau Insurance Companies
Lead System Programmer
Tom Longfellow
> We have IBM's DS-8100 DASD and are trying to get their Tivoli Storage
> Productivity Center for Disk(TPC) software to work. It seems to mostly
> work for the "dark side" people but we have not been able to get it to
> work for the mainframe side. It doesn't show the volser of the volume.
> It has something like CKD_0001. That's useless for our purposes.
>
First, I would like to thank you for justifying the money we have spent on
support and installation services.
We have had a DS8100 on the floor and operational for about six weeks and
the terminology alone confuses me. We also have CKD_0001 type names, but
they are a pool of CKD cylinders from which you define actual volumes.
But there are several things that have to happen first. Logical Control
Units (LCUS) must be defined. These are associated to the CKD cylinder
pools.
I have deleted and defined volumes but not directly through the TPC. I
have just used it to launch the web interface. Once in the web interface,
there are zSeries menu items that I just figured out by doing. It was good
for me that all of the prep work had been done by the paid installation
support.
My very inadequate guess at this point is that only the 'dark side' disk
constructs are fully defined and that there are some zSeries definitions
missing or incomplete.
Herring, Bobby
counts from SMF records? We've looked at file1 on the CBT tape and
didn't see anything that looked like it would collect printer statistics
from SMF.
We are at z/OS 1.10.
Thank you,
Bobby Herring
Texas Farm Bureau Insurance Companies
Lead System Programmer
----------------------------------------------------------------------
carlos roberto visconde
2009/11/9 Herring, Bobby <BHer...@txfb-ins.com>
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of carlos roberto visconde
> Sent: Monday, November 09, 2009 10:39 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: SMF Image counts and physical page counts
>
> Look at SMF records 6 and 26.
>
>
>
> 2009/11/9 Herring, Bobby <BHer...@txfb-ins.com>
>
> > Does anyone know of a way to obtain image counts and physical page
> > counts from SMF records? We've looked at file1 on the CBT tape and
> > didn't see anything that looked like it would collect
> printer statistics
> > from SMF.
But those don't show physical counts. That would require that the printer itself send information back to the system. For instance, when you duplex, that is one physical page but two "impressions" or "image counts". And other printers can do multiple up which place multiple pages on a single physical piece of paper. There is no what that I know of to get this information from SMF.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Ted MacNEIL
Unfortunately, for non-PSF, the page counts are not entirely accurate.
For one, extra separator pages are not collected (IIRC, even the first ones aren't).
For another, it isn't physical pages that are counted.
Rather, it's 'skip to channel 0' that's counted -- depending on the form -- there can/may be more than one per physical page.
For PSF (AFP), there are some issues with logical vs physical, especially with 2-up, 4-up (etc) and duplexed print.
Depending on the complexity of the form/overlay, your accuracy can vary.
The only accurate measure is the meter (on 3800's or later), but there is no api (that I know of).
If you're using it for billing/chargeback, it might be good enough, if you do some calibration before hand.
If you're doing it for throughput modelling, your better off using print times rather than lines, pages, impressions, or feet.
Even that has a few issues due to buffers and how long before the SMF record is written after the output has been purged.
-
Too busy driving to stop for gas!
Ted MacNEIL
PSF reports it within the AFP version of the type-6 SMF record -- impressions.
It's accuracy varies, but you can calibrate it.
Ed Finnell
In a message dated 11/9/2009 11:03:02 A.M. Central Standard Time,
eama...@YAHOO.CA writes:
PSF reports it within the AFP version of the type-6 SMF record --
impressions.
It's accuracy varies, but you can calibrate it.
>>
Been awhile, but used to use ANALPRT from MXG. Think Dr. Barry used 6's
with 26's to get thruput metrics. Think for Image vs page you'd have to know
the N-up from the PAGEDEF. Don't know if this available in newer versions
of PSF.
Barry Merrill
have not been updated in several years, but I believe they
are still correct with regard to what is counted where.
Barry Merrill
PRINTERS
The TYPE6 record data in the PDB.PRINT data set provides the data needed
to distribute the cost of printing to the end-user. The method used in
distributing these costs depends on the type(s) of printers used. What
works for one class might not work for other classes of printers.
For older line printers, charges based on the number of lines printed is
probably the most accurate and equitable method. For some of the the
early laser printers (like the IBM 3800-1) the line count can be
distorted by font changes within lines but counting lines printed is
still the best method. The PDB.PRINT variable TOTLINES, which is
TOTLINES=SUM(PRINTLNE,PUNCHCRD,EXTWTRLN), must be used to count lines.
Almost all lines printed now are counted in the EXTWTRLN field, because
IBM changed OUTDEVCE (it used to contain the name of the printer or
punch, but it now contains the VTAM node name, so PRint versus PUnch can
not be detected, and EXTWTRLN is the fall-thru bucket!).
PSF printers should be billed based on the number of sheets printed,
SHEETPRN, which is the number of physical page sides that were printed.
SHEETPRN per minute is a good printer throughput measure; the printer
can never produce sheets at more than the rated speed of the printer,
and thus using SHEETPRN recovers the cost of the individual pieces of
paper, and the exclusive use of the printer. Alternatively for PSF, you
may want to consider the use of DOCLENFT (the length of the paper
printed). This number is useful because the meter that is read by the
CE each month is measuring the number of feet of paper that passes
beneath the print head and thus your printer maintanence bill is
directly related to DOCLENFT. There is one small problem with this
number that only applies to continuous form printers like the IBM
3800-3. DOCLENFT is always measured in the direction of paper flow. In
the case of a cut sheet printer, this is ALWAYS across the 8.5 inch side
of a standard size sheet of paper. Continuous forms can be obtained
with the tractor feed on either the 8.5 inch sides or the 11 inch sides
and the same document can be produced on either stock simply by rotating
the text (which may be as simple as changing the form number.) Thus a
100 page job could potentially reflect 70.8 feet one day and 91.75 on
another simply by changing the paper. If you are still using the forms
with the feed on the long side, you may want to evaluate the possible
cost savings of using the other orientation of the paper. What about
PAGECNT? Don't use it. To PSF printers, one page is one sheet of paper
whether SIMPLEX or DUPLEX. Thus a user printing a 100 page document
DUPLEX would be billed for 50 pages while a SIMPLEX user would be billed
100 pages for the same document.
What is in TOTLINES under PSF? It all depends: line-mode data counts
the number of line images spooled in TOTLINES, and PSF-mode data counts
the number of records spooled, but a record could be single line or a
multi-page graph. You can tell that PSF created the type 6 data because
variable SUBSYS6='PSF' (others are: JES2,JES3,EXTW,SAR,EXD,CADI,BUND),
but there's nothing in the type 6 to identify the print's data mode.
Nov 2005 notes:
1. TOTLINES can be very large when the record has a file transfer
segment (variable SMF6BYTE will be non missing).
2. IBM variable SMF6PRMD does identify LINE vs PAGE mode in SMF 6 PSF
records.
Print workstation printers (Xerox printers like the 4050, 4090, 4135,
and 9700s) present other challenges, because they contain their own
operating systems and disk storage (early Xerox used a PDP 11 inside),
and the PDB.PRINT information represents only what was sent by JES or
PSF to the print workstation. PRINTIME/PRENTIME are the time print was
transmitted, and not when actually printed. These printers can store
the SYSOUT, print the SYSOUT, copy it to tape or floppy, or purge the
output prior to printing all without notifying the MVS host of the
action taken! To further muddy the water, there are commands, called
DJDEs, that can be sent along with the datastream to modify the number
of copies, to set print to SIMPLEX or DUPLEX, to set how many logical
pages are on a physical page, etc. This all means that any relationship
between the TYPE6 record and what actually happened on these printers is
purely coincidental. The good news is that there is a Xerox-provided
facility, SFS, that will create a billing record of each
job printed with the print facilities actually used, including the
number of sheets of paper printed and which bins were used. The
bad news is that SFS does not automatically send these data records to
the mainframe, and that you must modify SFS (see the example in member
ADOCSFS) to add the JOB name and JESNR to the SFS record.
Although special forms are less common than earlier, they still exist
and users should be charged for the use and storage of the special forms
that they use. All of these data sources provide indications of the
forms that were used and these should be charged based on the operator
time to mount the form (like a tape mount) and the cost of storing the
blank forms (like a tape volume.)
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On Behalf Of