In , on
03/26/2015
at 12:48 PM, "Nims,Alva John (Al)" said:
>The picture is not very good though. A google search of "360/195"
>got a few hits that may support that the ancestor is a 360/19x
19x? The only 3-digit S/360 model was 195. Did you mean 360/9x?
--
Shmuel (Seymour J.) Metz,
(Just picked off the last note in the thread.) I hate to leave this intriguing
discussion without a stab at lessons learned. Given that the problem was
finally solved and remediated through a PE APAR, there are a couple of actions
that might have led to faster resolution.
1. Rigorously pull th
This has been discussed recently, also on IBM-Main.
Look here:
https://listserv.ua.edu/cgi-bin/wa?A2=ind1502&L=ibm-main&F=&S=&P=563359
See 3rd paragraph.
In general, with CSV the values have to be quoted (at least char values),
because they may contain the separation character, and if they wer
If you use the cp command you can do something like
cp -F crnl ... dataset options .. file dataset
The exact syntax is in the book.
Rob Schramm
Senior Systems Consultant
On Tue, Mar 24, 2015 at 1:38 PM, Kevin Landin wrote:
> Thank you for the responses.
>
> I could not find an OCOPY option
So I did a couple of internet searches and came up with this
http://bit.listserv.ibm-main.narkive.com/weG3Xf5c/getting-iee707i-message-with-start-command
Before processing command cm yyy, MVS presented the command to all subsystems
that monitor commands. Based on the response returned, MVS did no
I entered some Jes2 commands to run under the timed commands feature
mentioned in the subject. The command(s) are quit complex and include
search of appropriate jobs to act on. When a command like $T JC,/JN
=xxx*,QUEUE=XEQ,/C=K,C=P entered from Jes automatic commands, I get an
IEE707I msg, which in
Thanksa lot Kolusu for putting this. Let me see how to overcome this issue ..
Thanks!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>I need to download as CSV file with out the extra 2 bytes
Ron,
Something does NOT make sense. If I understand the whole idea of
downloading a file as CSV file is to send to a PC Platform and these files
would be viewed using programs like EXCEL. EXCEL does sometimes strange
things as it trie
Thanks Kolusu.. I looked at the manual and there also when we need to unload
to a CSV file then CSV paramters need to get coded , but the problem is when is
code that extra 2 byte is comming. I need to download as CSV file with out the
extra 2 bytes . Is there a way for that ? Thanks!
-
>>Now the table gets unloaded with the out the pipe symbol. The parameters
provided is as follows
Ron,
Well your initial question is the why your unload has 2 extra bytes and
now you know the reason for that. Now coming to your latest question,
about not having the separator, did you try look
Ok Kolusu. Now the table gets unloaded with the out the pipe symbol. The
parameters provided is as follows
$$FILEM DBX OBJIN="PUSMDW01"."CUS_STO",
$$FILEM OUTPUT=FMNOUT,
$$FILEM NULLIND=_,
$$FILEM SEPARATOR='|',
$$FILEM ROWS=ALL
Thanks
Ron T
-
> MNBA355 Record size (546) invalid for FIXED,1696 output
Ron,
The actual message is FMNBA355 which specifies that your DCB parms coded
in your JCL does not match the output length generated by your unload
The first job you showed is unloading a different table from the latest
one, so you need
On Thu, 26 Mar 2015 12:17:11 -0400, David L. Craig wrote:
>On 15Mar26:0928-0500, Norbert Friemel wrote:
>>
>> S/360 Model 91
>>
>> Higher resolutions @
>> https://www.flickr.com/photos/epitti/2371701458/sizes/l/in/photostream/
>> https://www.flickr.com/photos/epitti/2370869637/sizes/l/in/photostr
Hello.
I modified the control card as below by removing all the CSV Parameters
$$FILEM DBX OBJIN="PUSMDW01"."CUS_STO",
$$FILEM OUTPUT=FMNOUT,
$$FILEM NULLIND=_,
$$FILEM SEPARATOR='|',
$$FILEM ROWS=ALL
i am getting the below error message
BM File Manager for z/OS DB2 Component
MNBA355 Record siz
Ron,
Probably due to $$FILEM CSV=YES, which would make FM enclose the data in
quotes so that excel would treat the data as plain text.
Try removing ALL the CSV parms and see if you still get the extra 2 bytes.
Thanks,
Kolusu
From: Ron Thomas
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 03/
Hi . I am unlaoding a table and one of the columns the defintion is shown as
below
CUS_BIL_ADDRCHAR(26) FOR SBCS DATA NOT NULL
Now when i unload the table it is showing as 28 characters in the download file
"""A COLORADO CORPORATION""" . Kindly let me know why the extra 2 byte is
co
Venkat,
Assuming it's JES2 (I don't know how JES3 deals with that), this will also
depend on how MSGCLASS=H is defined in OUTCLASS parm of your JES2 control
datasets, which are pointed in HASPPARM DD in JES2 proc.
---
On 15Mar26:0928-0500, Norbert Friemel wrote:
>
> S/360 Model 91
>
> Higher resolutions @
> https://www.flickr.com/photos/epitti/2371701458/sizes/l/in/photostream/
> https://www.flickr.com/photos/epitti/2370869637/sizes/l/in/photostream/
Inquiring minds want to know: where's the Emergency Pull?
Thanks . How do I view that class.
On Thu, Mar 26, 2015 at 8:32 PM, Lizette Koehler
wrote:
> If your SDSF is controlled by ISFPARMs or RACF - you will need to provide
> the access you need. You need to use a USERID that has authority to view
> that class.
>
>
> Lizette
>
>
> > -Original Mes
On 26 Mar 2015 03:33:25 -0700, in bit.listserv.ibm-main you wrote:
>
>* USERS AFFECTED: IEBCOPY of a RECFM=F or RECFM=FB PDSE
>* results in a broken PDSE. The only members
>* which can be accessed in t
On 26 March 2015 at 08:06, Don Poitras wrote:
> The special thanks should really go to Bob Rutledge. He's the one that pointed
> out the APAR. Tony just gave you a "public" url.
I was about to point that out. Thanks for doing it for me. :-)
Tony H.
basking in undeserved glory...
---
If your SDSF is controlled by ISFPARMs or RACF - you will need to provide the
access you need. You need to use a USERID that has authority to view that
class.
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of venkat ku
On Thu, 26 Mar 2015 06:38:12 -0500, John McKown wrote:
>Why did they put in a picture of "an ancestor of the z13"? I'll grant
>that the old machines really did look a lot more "computer-ish" than
>today's "pizza box" and "refridgerator" forms. Oh, for the days of
>spinning tapes and card sorters.
Generally, we use message class A in our JCL and we get output in SD.ST to
view the Job log. But Today somebody used message class H in JCL but now I
dont find his job long in SD.ST.
Can anybody suggest, how can I view his job log.
Thanks in advance.
-
On Thu, 26 Mar 2015 06:38:12 -0500, John McKown wrote:
>Why did they put in a picture of "an ancestor of the z13"? I'll grant
>that the old machines really did look a lot more "computer-ish" than
>today's "pizza box" and "refridgerator" forms. Oh, for the days of
>spinning tapes and card sorters.
I've called this author out before on another article of his on Forbes about 4
months. His response was:
"I enjoy posting photos of important technology of the past to give readers
some context. But in truth, I simply think photos of old technology are cool!"
Thanks,
Mark Regan
USNR-Ret. [1969
Start at that link and click a few times on the right arrow and get to the
"Model 91" and I think we have our answer or:
http://en.wikipedia.org/wiki/IBM_System/360#/media/File:IBM_System_36091.sj.jpg
Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-129
I found:
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2195.html
The picture is not very good though. A google search of "360/195" got a few
hits that may support that the ancestor is a 360/19x
Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(
http://en.wikipedia.org/wiki/IBM_System/360#/media/File:IBM_System_360-30_front_panel.agr.jpg
On Thu, Mar 26, 2015 at 7:35 AM, Mike Schwab wrote:
> S/360.
>
> On Thu, Mar 26, 2015 at 6:38 AM, John McKown
> wrote:
>> Why did they put in a picture of "an ancestor of the z13"? I'll grant
>> that th
Yeah, Mike that's what I thought. Heard of a s360/195 had never seen one.
Regards,
Scott
On Thursday, March 26, 2015, Mike Schwab wrote:
> S/360.
>
> On Thu, Mar 26, 2015 at 6:38 AM, John McKown
> > wrote:
> > Why did they put in a picture of "an ancestor of the z13"? I'll grant
> > that the ol
S/360.
On Thu, Mar 26, 2015 at 6:38 AM, John McKown
wrote:
> Why did they put in a picture of "an ancestor of the z13"? I'll grant
> that the old machines really did look a lot more "computer-ish" than
> today's "pizza box" and "refridgerator" forms. Oh, for the days of
> spinning tapes and card
John,
Is that a 360/195 ?
On Thursday, March 26, 2015, John McKown > wrote:
> Why did they put in a picture of "an ancestor of the z13"? I'll grant
> that the old machines really did look a lot more "computer-ish" than
> today's "pizza box" and "refridgerator" forms. Oh, for the days of
> spinni
Very true, Don. That must have temporarily slipped my attention. May I blame it
on lack of sleep? ;-)
Special thanks to Bob Rutledge as well, of course!
And, once again: I do appreciate y'all's input and help.
Regards
Karl
-Original Message-
From: IBM Mainframe Discussion List [mailto
The special thanks should really go to Bob Rutledge. He's the one that pointed
out the APAR. Tony just gave you a "public" url.
In article
you wrote:
> World,
> Luckily, I'm not crazy. Who would have thought that ...?
> The error was introduced with the PTFs for OA46598, which were: UA75869
Why did they put in a picture of "an ancestor of the z13"? I'll grant
that the old machines really did look a lot more "computer-ish" than
today's "pizza box" and "refridgerator" forms. Oh, for the days of
spinning tapes and card sorters. [grin]. BTW - what is that a picture
of?
On Thu, Mar 26, 20
Interesting article about the mainframe in Forbes:
http://www.forbes.com/sites/jasonbloomberg/2015/03/24/digital-cloud-modern-and-cost-effective-surprise-its-the-mainframe/
tiny'd: http://preview.tinyurl.com/pv3wwz9
--
Tom Marchant
--
* USERS AFFECTED: IEBCOPY of a RECFM=F or RECFM=FB PDSE
* results in a broken PDSE. The only members
* which can be accessed in the target PDSE
* are the empty members.
***
World,
Luckily, I'm not crazy. Who would have thought that ...?
The error was introduced with the PTFs for OA46598, which were: UA75869 (D10)
and UA75875 (210).
There is a fairly fresh APAR that addresses this problem; OA47338 (special
thanks to Tony Harminc for pointing me to this yesterday).
Thanks a lot, Tony!
I don't know why I didn't see/find it yesterday. The error description of this
brand-new APAR does exactly fit the situation I'm facing. I'll RESTORE UA75875
right away in order to verify this.
Regards,
Karl
-Original Message-
From: IBM Mainframe Discussion List [m
39 matches
Mail list logo
